From report at bugs.python.org  Fri May  1 00:13:12 2009
From: report at bugs.python.org (George Sakkis)
Date: Thu, 30 Apr 2009 22:13:12 +0000
Subject: [New-bugs-announce] [issue5890] Subclassing property doesn't
	preserve the auto __doc__	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>


New submission from George Sakkis <george.sakkis at gmail.com>:

Is the following behavior expected ?

class MyProp(property):
    pass

class Foo(object):
    @property
    def bar(self):
        '''Get a bar.'''

    @MyProp
    def baz(self):
        '''Get a baz.'''

    
>>> print Foo.bar.__doc__ 
Get a bar.
>>> print Foo.baz.__doc__
None

----------
messages: 86859
nosy: gsakkis
severity: normal
status: open
title: Subclassing property doesn't preserve the auto __doc__ behavior
type: behavior

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

From report at bugs.python.org  Fri May  1 06:51:03 2009
From: report at bugs.python.org (David Stemmer)
Date: Fri, 01 May 2009 04:51:03 +0000
Subject: [New-bugs-announce] [issue5891] strange list.sort() behavior on
	import, del and inport again
In-Reply-To: <1241153462.53.0.480786919372.issue5891@psf.upfronthosting.co.za>
Message-ID: <1241153462.53.0.480786919372.issue5891@psf.upfronthosting.co.za>


New submission from David Stemmer <dstemmer at brandeis.edu>:

Given two modules, I've seen the following kind of strange behavior with
list sorting on import and delete; a list that has been imported, sorted
and deleted remains sorted on a second import:

my_module.py:

some_list = ['b','a']

other_module.py:

from  my_module import some_list
print some_list
some_list.sort()
print some_list
del some_list
from  my_module import some_list
print some_list

Output is:

['b','a']
['a','a']
['a','b']

Sorry if it's already been reported.

----------
files: bugs.rar
messages: 86861
nosy: dstemmer
severity: normal
status: open
title: strange list.sort() behavior on import, del and inport again
versions: Python 2.6
Added file: http://bugs.python.org/file13825/bugs.rar

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

From report at bugs.python.org  Fri May  1 06:52:00 2009
From: report at bugs.python.org (David Stemmer)
Date: Fri, 01 May 2009 04:52:00 +0000
Subject: [New-bugs-announce] [issue5892] strange list.sort() behavior on
	import, del and inport again
In-Reply-To: <1241153520.12.0.753692294118.issue5892@psf.upfronthosting.co.za>
Message-ID: <1241153520.12.0.753692294118.issue5892@psf.upfronthosting.co.za>


New submission from David Stemmer <dstemmer at brandeis.edu>:

Given two modules, I've seen the following kind of strange behavior with
list sorting on import and delete; a list that has been imported, sorted
and deleted remains sorted on a second import:

my_module.py:

some_list = ['b','a']

other_module.py:

from  my_module import some_list
print some_list
some_list.sort()
print some_list
del some_list
from  my_module import some_list
print some_list

Output is:

['b','a']
['a','b']
['a','b']

Sorry if it's already been reported.

----------
files: bugs.rar
messages: 86862
nosy: dstemmer
severity: normal
status: open
title: strange list.sort() behavior on import, del and inport again
versions: Python 2.6
Added file: http://bugs.python.org/file13826/bugs.rar

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

From report at bugs.python.org  Fri May  1 09:01:26 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 May 2009 07:01:26 +0000
Subject: [New-bugs-announce] [issue5893] Add support to pydoc to output .rst
	restructured text
In-Reply-To: <1241161286.71.0.465888243083.issue5893@psf.upfronthosting.co.za>
Message-ID: <1241161286.71.0.465888243083.issue5893@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

When writing documentation for a module that is already well documented
in its docstrings, I really wish pydoc could output .rst directly.

It'd mean much less manual editing.

----------
components: Demos and Tools
messages: 86866
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Add support to pydoc to output .rst restructured text
type: feature request

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

From report at bugs.python.org  Fri May  1 09:24:49 2009
From: report at bugs.python.org (pander)
Date: Fri, 01 May 2009 07:24:49 +0000
Subject: [New-bugs-announce] [issue5894] Lookup of localised language name
	by ISO 639 language	code and reverse look up
In-Reply-To: <1241162689.75.0.736429390254.issue5894@psf.upfronthosting.co.za>
Message-ID: <1241162689.75.0.736429390254.issue5894@psf.upfronthosting.co.za>


New submission from pander <pander at users.sourceforge.net>:

Hi all,

Does a module exist that can look up localised language names for ISO
639 language codes? If not, could one be constructed according to (sort
of) the following specifications?

1) Look up a localised language name for an ISO 639-1 language code for
a required parameter named code, providing the language code, and an
optional parameter named lang, providing the output language code, which
by default is set to 'en'. Example input and output would would be:

iso6391name(code='en') => 'English'
iso6391name(code='zu', lang='en') => 'Zulu'
iso6391name(code='zu', lang='nl') => 'Zoeloe'
iso6391name(code='nl', lang='en') => 'Dutch'

2) Reverse lookup of 1) from localised language to language code, e.g.:
iso6391code(name='English') => 'en'
iso6391code(name='Zulu', lang='en') => 'zu'
iso6391code(name='Zoeloe', lang='nl') => 'zu'
iso6391code(name='Dutch', lang='en') => 'nl'

3) Look up native language name for an ISO 639-1 language code for a
required parameter named code, providing the language code. Example
input and output would would be:

iso6391native(code='en') => 'English'
iso6391native(code='nl) => 'Nederlands'

4) Retrieving a tuple with all language codes. Example output would be:

iso6391codes() => ('aa', 'ab', ..., 'zu')

5) Retrieving a tuple with all localised language names for an optional
parameter named lang, providing the output language code, which by
default is set to 'en'. Example input and output would be:

iso6391names() => ('Afar', 'Abkhazian', ..., 'Zulu')
iso6391names(lang='nl') => ('Afar', 'Abchazisch', ..., 'Zoeloe')

6), 7), 8), 9), 10) Something similar for ISO 639-2 language codes

11), 12), 13), 14), 15) Something similar for ISO 639-2 language codes

sources:
http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
http://nl.wikipedia.org/wiki/Lijst_van_ISO_639-1-codes

I have a very simple implementation for English and Dutch but figured
that such a module should be available for all developers in all
languages. Hence this request to build something from scratch in the
Python localisation community.

Implementing functionality as described above will boost the ease of
internalisation and localisation of Python applications.

Please reply to this issue for constructive feedback.

Thanks,

Pander

PS   The original post in i18n-sg is here:
  http://mail.python.org/pipermail/i18n-sig/2009-April/002117.html

----------
messages: 86867
nosy: pander
severity: normal
status: open
title: Lookup of localised language name by ISO 639 language code and reverse look up
type: feature request

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

From report at bugs.python.org  Fri May  1 18:37:54 2009
From: report at bugs.python.org (Naoyuki Tai)
Date: Fri, 01 May 2009 16:37:54 +0000
Subject: [New-bugs-announce] [issue5895] socketmodule.c on HPUX ia64
	without	_XOPEN_SOURCE_EXTENDED compiles incorrectly
In-Reply-To: <1241195874.94.0.470854501498.issue5895@psf.upfronthosting.co.za>
Message-ID: <1241195874.94.0.470854501498.issue5895@psf.upfronthosting.co.za>


New submission from Naoyuki Tai <ntai at users.sourceforge.net>:

Python can build without _XOPEN_SOURCE_EXTENDED on HPUX ia64 but the
socket module is bust.
This is because APIs like getsockname() do not use socklen_t*. Instead
it is defined using int* for some of arguments.
In socketmodule.c, it consistently use socklent_t which is the right
thing for the rest of world.
Because socklent_t is 64bit (same as size_t) and int is 32bit, it
compiles with warnings of different types of pointer but it compiles anyway.
The result is that, getsockname(), etc. take a look at the 32bit out of
64bit value thinking it is "zero" (big endian machine).
APIs succeed without error but the result does not come back since the
API calls think that the return value buffer size is 0.

My Python build is 2.5. I think the same is true for all versions
thereafter. I wish I could give you a diff but I don't know well enough
the socketmodule.c what's the right thing to do.
I cannot use _XOPEN_SOURCE_EXTENDED as I have other python bindings and
modules built without _XOPEN_SOURCE_EXTENDED.

----------
components: Extension Modules
messages: 86889
nosy: ntai
severity: normal
status: open
title: socketmodule.c  on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri May  1 19:53:50 2009
From: report at bugs.python.org (how rabbit feels)
Date: Fri, 01 May 2009 17:53:50 +0000
Subject: [New-bugs-announce] [issue5896] timeit documentation
In-Reply-To: <1241200430.17.0.749564261591.issue5896@psf.upfronthosting.co.za>
Message-ID: <1241200430.17.0.749564261591.issue5896@psf.upfronthosting.co.za>


New submission from how rabbit  feels <hrfeels at gmail.com>:

It should be noted in the documentation that the 'setup' argument may be
a semicolon delimited list of imports:

Example:

t = timeit.Timer('squeezer.testRegular()', 'import squeezer; from
squeezer import myStaticData1, myStaticData2, testRegular')



related issues: 2527, 5441, 1397474

----------
assignee: georg.brandl
components: Documentation
messages: 86891
nosy: georg.brandl, hrfeels
severity: normal
status: open
title: timeit documentation
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri May  1 20:44:23 2009
From: report at bugs.python.org (Suraj Barkale)
Date: Fri, 01 May 2009 18:44:23 +0000
Subject: [New-bugs-announce] [issue5897] No library reference tree in chm
	help file
In-Reply-To: <1241203463.4.0.587684718574.issue5897@psf.upfronthosting.co.za>
Message-ID: <1241203463.4.0.587684718574.issue5897@psf.upfronthosting.co.za>


New submission from Suraj Barkale <suraj+python at barkale.com>:

In the windows help file installed with Python 2.6.2, many topics (e.g.
"Python Standard Library") are shown are leaf nodes instead of books.
After checking source code, `:numbered:` clause was added to many
index.rst files in revision 71270. The TOC for these files no longer
appears in the CHM viewer.

----------
assignee: georg.brandl
components: Documentation
messages: 86892
nosy: georg.brandl, suraj
severity: normal
status: open
title: No library reference tree in chm help file
versions: Python 2.6

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

From =?utf-8?q?Fran=C3=A7ois_Granade_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Fri May  1 22:08:08 2009
From: =?utf-8?q?Fran=C3=A7ois_Granade_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Fran=C3=A7ois_Granade_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 20:08:08 +0000
Subject: [New-bugs-announce] [issue5898] Hang in Popen.wait() when another
	process has been created
In-Reply-To: <1241208488.61.0.0189551533272.issue5898@psf.upfronthosting.co.za>
Message-ID: <1241208488.61.0.0189551533272.issue5898@psf.upfronthosting.co.za>


New submission from Fran?ois Granade <francois at granade.com>:

If I remove the "proc2.stdin.close()" in the script below, the
"proc1.wait()" will hang. Tested on MacOS, Linux, CygWin on 2.5.2 and
2.6. Is it a bug ?

from subprocess	import Popen, PIPE
proc1 =	Popen('cat -', shell=True, stdin=PIPE, stdout=PIPE)
proc2 = Popen('cat -', shell=True, stdin=PIPE, stdout=PIPE)
# Removing this line make the proc1.wait() hang
proc2.stdin.close()

proc1.stdin.close()
proc1.wait()

----------
components: Library (Lib)
messages: 86901
nosy: farialima
severity: normal
status: open
title: Hang in Popen.wait() when another process has been created
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri May  1 23:38:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:38:27 +0000
Subject: [New-bugs-announce] [issue5899] test_capi crashes when called more
	than once
In-Reply-To: <1241213907.75.0.583919845233.issue5899@psf.upfronthosting.co.za>
Message-ID: <1241213907.75.0.583919845233.issue5899@psf.upfronthosting.co.za>


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

This happens when looking for reference leaks:

$ ./python -m test.regrtest -R3:2 test_capi
Could not find '/home/antoine/py3k/debug/Lib/test' in sys.path to remove it
test_capi
beginning 5 repetitions
12345
test test_capi crashed -- <class '_testcapi.error'>:
test_lazy_hash_inheritance: type initialised too soon
1 test failed:
    test_capi
[93567 refs]

----------
assignee: ncoghlan
components: Tests
messages: 86914
nosy: ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi crashes when called more than once
type: crash
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat May  2 00:56:05 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 01 May 2009 22:56:05 +0000
Subject: [New-bugs-announce] [issue5900] Ensure RUNPATH is added to
	extension modules with RPATH	if GNU ld is used
In-Reply-To: <1241218565.03.0.0824353147466.issue5900@psf.upfronthosting.co.za>
Message-ID: <1241218565.03.0.0824353147466.issue5900@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

The build_ext command does accept a handy --rpath option to encode an
RPATH in the built extension modules.  However RPATH is superseded by
RUNPATH since the former can not be overwritten by the LD_LIBRARY_PATH
environment varialbe, while the later can.  While most linkers will add
a RUNPATH automatically when you ask for an RPATH, GNU ld does not do
this.  Therefore this patch does detect if GNU ld is used and if so will
use the --enable-new-dtags option which will add the RUNPATH.

----------
assignee: tarek
components: Distutils
files: runpath.diff
keywords: patch
messages: 86924
nosy: flub, tarek
severity: normal
status: open
title: Ensure RUNPATH is added to extension modules with RPATH if GNU ld is used
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13833/runpath.diff

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

From report at bugs.python.org  Sat May  2 08:42:58 2009
From: report at bugs.python.org (Vito De Tullio)
Date: Sat, 02 May 2009 06:42:58 +0000
Subject: [New-bugs-announce] [issue5901] missing meta-info in documentation
	pdf
In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za>
Message-ID: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za>


New submission from Vito De Tullio <vito.detullio at gmail.com>:

from http://docs.python.org/download.html and
http://docs.python.org/3.0/download.html you can download the python
documentation in many formats (html, pdf, txt), I think auto-generated
by the .rst source.

While html and txt does not, the pdf format, supports some simple
"meta-data" infos about the document: other than the number of pages,
the page size, the creator, etc... (all auto-filled) there are 4 "keys"
that the current pdf miss to fill and I think it's important: Title,
Subject, Keywords, and Author.

try, for example, to use the simple pdfinfo tool (from
http://poppler.freedesktop.org/) to inspect the current pdf

$ tar xvjf python-3.0.1-docs-pdf-a4.tar.bz2
$ cd docs-pdf
$ ls -1
c-api.pdf
distutils.pdf
documenting.pdf
extending.pdf
howto-advocacy.pdf
howto-cporting.pdf
howto-curses.pdf
howto-doanddont.pdf
howto-functional.pdf
howto-regex.pdf
howto-sockets.pdf
howto-unicode.pdf
howto-urllib2.pdf
howto-webservers.pdf
install.pdf
library.pdf
reference.pdf
tutorial.pdf
using.pdf
whatsnew.pdf
$ pdfinfo library.pdf
Title:
Subject:
Keywords:
Author:
Creator:        LaTeX with hyperref package
Producer:       pdfTeX-1.40.9
CreationDate:   Sat Feb 14 11:33:09 2009
ModDate:        Sat Feb 14 11:33:09 2009
Tagged:         no
Pages:          1077
Encrypted:      no
Page size:      595.276 x 841.89 pts (A4)
File size:      7556857 bytes
Optimized:      no
PDF version:    1.4

erh, what is supposed to contain "using.pdf"? and "distutils.pdf"?

(Yes, I know what they contain, but...)

If the pdf were "tagged", not only me, but also my OS will know what's
in these pdf (see nepomuk/strigi/tracker/beagle programs, helping me
find what I'm searching

----------
assignee: georg.brandl
components: Documentation
messages: 86931
nosy: ZeD, georg.brandl
severity: normal
status: open
title: missing meta-info in documentation pdf
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Sat May  2 10:00:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 May 2009 08:00:20 +0000
Subject: [New-bugs-announce] [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

I noticed that codec names[1]:
1) can contain random/unnecessary spaces and punctuation;
2) have several aliases that could probably be removed;

A few examples of valid codec names (done with Python 3):
>>> s = 'xxx'
>>> s.encode('utf')
b'xxx'
>>> s.encode('utf-')
b'xxx'
>>> s.encode('}Utf~->8<-~siG{ ;)')
b'\xef\xbb\xbfxxx'

'utf' is an alias for UTF-8 and that doesn't quite make sense to me that
'utf' alone refers to UTF-8.
'utf-' could be a mistyped 'utf-8', 'utf-7' or even 'utf-16'; I'd like
it to raise an error instead.
The third example is not probably something that can be found in the
real world (I hope) but it shows how permissive the parsing of the names is.

Apparently the whitespaces are removed and the punctuation is used to
split the name in several parts and then the check is performed.


About the aliases: in the documentation the "official" name for the
UTF-8 codec is 'utf_8' and there are 3 more aliases: U8, UTF, utf8. For
ISO-8859-1, the "official" name is 'latin_1' and there are 7 more
aliases: iso-8859-1, iso8859-1, 8859, cp819, latin, latin1, L1.
The Zen says "There should be one?and preferably only one?obvious way to
do it.", so I suggest to
1) disallow random punctuation and spaces within the name (only allow
leading and trailing spaces);
2) change the default names to, for example: 'utf-8', 'iso-8859-1'
instead of 'utf_8' and 'iso8859_1'. The name are case-insentive.
3) remove the unnecessary aliases, for example: 'UTF', 'U8' for UTF-8
and 'iso8859-1', '8859', 'latin', 'L1' for ISO-8859-1;

This last point could break some code and may need some
DeprecationWarning. If there are good reason to keep around these codecs
only the other two issues can be addressed. 
If the name of the codec has to be a valid variable name (that is,
without '-'), only the documentation could be changed to have 'utf-8',
'iso-8859-1', etc. as preferred name.

[1]: http://docs.python.org/library/codecs.html#standard-encodings
     http://docs.python.org/3.0/library/codecs.html#standard-encodings

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 86933
nosy: ezio.melotti, georg.brandl
severity: normal
status: open
title: Stricter codec names
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat May  2 15:19:15 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 02 May 2009 13:19:15 +0000
Subject: [New-bugs-announce] [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

On Mac OS X 10.5

$ LC_ALL=ru_RU.koi8-r python3.0 -c 'import time;print( time.strftime("%A"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
invalid data

----------
components: Library (Lib)
messages: 86944
nosy: barry-scott
severity: normal
status: open
title: strftime fails in non UTF-8 locale
versions: Python 3.0

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

From report at bugs.python.org  Sat May  2 15:25:39 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 02 May 2009 13:25:39 +0000
Subject: [New-bugs-announce] [issue5904] strftime docs do not explain locale
	affect on result	string
In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za>
Message-ID: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

The result of time.strftime seems to be in the locale encoding
but this is not pointed out in the documentation.

Ideally an example like this would be in the docs to show how to
deal with strftime output:

import locale
import time

locale_encoded_time = time.strftime( '%d-%b-%Y %H:%M:%S' )

language, encoding = locale.getdefaultlocale()
unicode_time = locale_encoded_time.decode( encoding )

----------
assignee: georg.brandl
components: Documentation
messages: 86946
nosy: barry-scott, georg.brandl
severity: normal
status: open
title: strftime docs do not explain locale affect on result string
versions: Python 2.6

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

From report at bugs.python.org  Sat May  2 17:17:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 15:17:21 +0000
Subject: [New-bugs-announce] [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>


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

time.strptime() fails with non-UTF8 locales, *even when the input is
totally ASCII*.

>>> locale.setlocale(locale.LC_TIME, "fr_FR.ISO8859-15")
'fr_FR.ISO8859-15'
>>> time.strptime("2009-01-01", "%Y-%m-%d")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/_strptime.py", line 461, in
_strptime_time
    return _strptime(data_string, format)[0]
  File "/home/antoine/py3k/__svn__/Lib/_strptime.py", line 307, in _strptime
    _TimeRE_cache = TimeRE()
  File "/home/antoine/py3k/__svn__/Lib/_strptime.py", line 188, in __init__
    self.locale_time = LocaleTime()
  File "/home/antoine/py3k/__svn__/Lib/_strptime.py", line 72, in __init__
    self.__calc_month()
  File "/home/antoine/py3k/__svn__/Lib/_strptime.py", line 98, in
__calc_month
    a_month = [calendar.month_abbr[i].lower() for i in range(13)]
  File "/home/antoine/py3k/__svn__/Lib/_strptime.py", line 98, in <listcomp>
    a_month = [calendar.month_abbr[i].lower() for i in range(13)]
  File "/home/antoine/py3k/__svn__/Lib/calendar.py", line 60, in __getitem__
    return funcs(self.format)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3:
invalid data

----------
components: Library (Lib)
messages: 86953
nosy: pitrou
priority: critical
severity: normal
stage: test needed
status: open
title: strptime fails in non-UTF locale
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat May  2 18:28:00 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 02 May 2009 16:28:00 +0000
Subject: [New-bugs-announce] [issue5906] Risk of confusion in
	multiprocessing module - daemonic	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

"Usually, daemon processes are processes which got disconnected from
their parent process, and work in the background, often under a
different user identity.
The multiprocessing module has the concept of "daemon" too, but this
time in reference to the "threading" module, in which dameons are just
threads that wont prevent the application termination, even if they are
still running. Thus, daemonic processes launched through multiprocessing
API are normal processes that will be terminated (and not joined) if 
non-dameonic processes are all over."

I guess this difference of concepts would deserve a little paragraph of
clarification, in both multiprocessing and threading APIs (does the
paragraph above fit for that ?)

----------
components: Library (Lib)
messages: 86957
nosy: pakal
severity: normal
status: open
title: Risk of confusion in multiprocessing module - daemonic processes
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat May  2 18:30:43 2009
From: report at bugs.python.org (John Morton)
Date: Sat, 02 May 2009 16:30:43 +0000
Subject: [New-bugs-announce] [issue5907] repr of time.struct_time type does
	not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>


New submission from John Morton <jwm at angrymonkey.net.nz>:

The output of repr on an object of type time.struct_time has changed
from 2.5 to 2.6, and can no longer be read in with an eval.

2.5 behaviour:

Python 2.5.4 (r254:67916, Apr  4 2009, 17:55:16) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> t1 = time.gmtime()
>>> t1_repr = repr(t1)
>>> t1_repr
'(2009, 5, 2, 16, 16, 43, 5, 122, 0)'
>>> t2 = eval(t1_repr)
>>> t1 == t2
True

Meanwhile in 2.6:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> t1 = time.gmtime()
>>> t1_repr = repr(t1)
>>> t1_repr
'time.struct_time(tm_year=2009, tm_mon=5, tm_mday=2, tm_hour=16,
tm_min=20, tm_sec=54, tm_wday=5, tm_yday=122, tm_isdst=0)'
>>> t2 = eval(t1_repr)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
TypeError: structseq() takes at most 2 arguments (9 given)

Obviously returning a time.time_struct based representation is the right
thing to do, but the repr of this flavour should eval.

----------
components: Extension Modules, Tests
messages: 86958
nosy: jwm
severity: normal
status: open
title: repr of time.struct_time type does not eval
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat May  2 21:49:56 2009
From: report at bugs.python.org (tyoc)
Date: Sat, 02 May 2009 19:49:56 +0000
Subject: [New-bugs-announce] [issue5908] I need to import the module in the
	same thread?
In-Reply-To: <1241293796.19.0.916040418837.issue5908@psf.upfronthosting.co.za>
Message-ID: <1241293796.19.0.916040418837.issue5908@psf.upfronthosting.co.za>


New submission from tyoc <zaz at alum.com>:

Hi there, my problem is the following I dont know if this is a python 
error, spected behaviour or what, so here I go.

I'm using pyatspi in a console application for retrieve focus events
(you need to enable accessibility if want to check... that is at-spi-
registryd in 'top'):


Example 1: works correctly (focus events printed to stdout).
NOTE: See that the import is inside of 'run' and all the calls to the 
module are inside this thread.
FREEZE: No, correct behaviour.

[code start]--------------------------------------------
def cb(eve):
    print eve

import threading
class THRE4D(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
    def run(self):
        import pyatspi
        print 'spot 0'
        pyatspi.Registry.registerEventListener(cb, 'focus')
        import gobject
        print 'spot 1'
        gobject.timeout_add(5000, pyatspi.Registry.stop)
        print 'spot 2'
        pyatspi.Registry.start()
        print 'spot 3'

t = THRE4D()
t.start()
t.join(15000)
print 'joined'
[code end]--------------------------------------------

Example 2: it prints the first event and freeze quit because the 
timeout_add.
NOTE:See that I have moved the import and the register to __init__ the 
loop is in the new thread.
FREEZE: Yes. Print first event, dont know where it freeze (function), 
but has passed 'registerEventListener' and it has entered 
'Registry.start()'.

[code start]--------------------------------------------
def cb(eve):
    print eve

import threading
class THRE4D(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        import pyatspi
        pyatspi.Registry.registerEventListener(cb, 'focus')
    def run(self):
        import pyatspi
        print 'spot 0'
        import gobject
        print 'spot 1'
        gobject.timeout_add(5000, pyatspi.Registry.stop)
        print 'spot 2'
        pyatspi.Registry.start()
        print 'spot 3'

t = THRE4D()
t.start()
t.join(15000)
print 'joined'
[code end]--------------------------------------------

Example 3: It does not print any event at all and it freezes. It only 
prints 'spot 0'. The freeze is hard even that timeout_add doest end it 
in the time.
NOTE: See that I have only imported pyatspi in '__init__' all the calls 
are inside the thread.
FREEZE: Yes. No print of events, freeze inside inside 'accessible.py of 
pyatspi' in '_inner' where 'try: return func(self, *args, **kwargs)'.

[code start]--------------------------------------------
def cb(eve):
    print eve

import threading
class THRE4D(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        import pyatspi
    def run(self):
        import pyatspi
        print 'spot 0'
        pyatspi.Registry.registerEventListener(cb, 'focus')
        import gobject
        print 'spot 1'
        gobject.timeout_add(5000, pyatspi.Registry.stop)
        print 'spot 2'
        pyatspi.Registry.start()
        print 'spot 3'

t = THRE4D()
t.start()
t.join(15000)
print 'joined'
[code end]--------------------------------------------



actual conclusions

 * I dont know why importing it 2 times (pyatspi) in different context 
of threads launch this problem.

 * for a 'quick' solution: The import and the calls should be in the 
same thread "specially" 'registerEventListener'.

----------
components: Library (Lib), None
messages: 86975
nosy: tyoc
severity: normal
status: open
title: I need to import the module in the same thread?
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat May  2 23:14:13 2009
From: report at bugs.python.org (Gerald Britton)
Date: Sat, 02 May 2009 21:14:13 +0000
Subject: [New-bugs-announce] [issue5909] Segfault in typeobject.c
In-Reply-To: <1241298853.44.0.694039818999.issue5909@psf.upfronthosting.co.za>
Message-ID: <1241298853.44.0.694039818999.issue5909@psf.upfronthosting.co.za>


New submission from Gerald Britton <gerald.britton at gmail.com>:

Python 2.6 segfaults when starting up the gramps application

----------
assignee: theller
components: ctypes
files: gdb-python.txt
messages: 86981
nosy: gbritton, theller
severity: normal
status: open
title: Segfault in typeobject.c
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file13842/gdb-python.txt

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

From report at bugs.python.org  Sat May  2 23:58:08 2009
From: report at bugs.python.org (Erik Gorset)
Date: Sat, 02 May 2009 21:58:08 +0000
Subject: [New-bugs-announce] [issue5910] kqueue for more than one event is
	broken.
In-Reply-To: <1241301488.84.0.663629523973.issue5910@psf.upfronthosting.co.za>
Message-ID: <1241301488.84.0.663629523973.issue5910@psf.upfronthosting.co.za>


New submission from Erik Gorset <erik at gorset.no>:

The kqueue code doesn't increment the index when building the changelist.

The patch should work for both py26 and py30.

----------
components: Extension Modules
files: kqueue.patch
keywords: patch
messages: 86984
nosy: Erik Gorset
severity: normal
status: open
title: kqueue for more than one event is broken.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13844/kqueue.patch

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

From report at bugs.python.org  Sun May  3 03:55:25 2009
From: report at bugs.python.org (Naoki INADA)
Date: Sun, 03 May 2009 01:55:25 +0000
Subject: [New-bugs-announce] [issue5911] built-in compile() should take
	encoding option.
In-Reply-To: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>
Message-ID: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>


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

The built-in compile() expects source is encoded in utf-8.
This behavior make it harder to implement alternative shell
like IDLE and IPython. (http://bugs.python.org/issue1542677 and
https://bugs.launchpad.net/ipython/+bug/339642 are related bugs.)

Below is current compile() behavior.

# Python's interactive shell in Windows cp932 console.
>>> "?"
'\x82\xa0'
>>> u"?"
u'\u3042'

# compile() fails to decode str.
>>> code = compile('u"?"', '__interactive__', 'single')
>>> exec code
u'\x82\xa0'  # u'\u3042' expected.

# compile() encodes unicode to utf-8.
>>> code = compile(u'"?"', '__interactive__', 'single')
>>> exec code
'\xe3\x81\x82' # '\x82\xa0' (cp932) wanted, but I get utf-8.

Currentry, using PEP0263 like below is needed to get compile
code in expected encoding.

>>> code = compile('# coding: cp932\n%s' % ('"?"',), '__interactive__', 
'single')
>>> exec code
'\x82\xa0'
>>> code = compile('# coding: cp932\n%s' % ('u"?"',), '__interactive__', 
'single')
>>> exec code
u'\u3042'

But I feel compile() with PEP0263 is bit dirty hack.
I think adding a 'encoding' argument that have a 'utf-8' as default value to
compile() is cleaner way and it doesn't break backward compatibility.

Following example is describe behavior of compile() with encoding option.

# coding: utf-8 (in utf-8 context)
code = compile('"?"', '__foo.py', 'single')
exec code #=> '\xe3\x81\x82'

code = compile('"?"', '__foo.py', 'single', encoding='cp932') => 
UnicodeDecodeError

code = compile(u'"?"', '__foo.py', 'single')
exec code #=> '\xe3\x81\x82'

code = compile(u'"?"', '__foo.py', 'single', encoding='cp932')
exec code #=> '\x82\xa0'

----------
components: None
messages: 86994
nosy: naoki
severity: normal
status: open
title: built-in compile() should take encoding option.
type: feature request
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun May  3 13:50:28 2009
From: report at bugs.python.org (ayal baron)
Date: Sun, 03 May 2009 11:50:28 +0000
Subject: [New-bugs-announce] [issue5912] import deadlocks when using fork
In-Reply-To: <1241351428.83.0.293714766412.issue5912@psf.upfronthosting.co.za>
Message-ID: <1241351428.83.0.293714766412.issue5912@psf.upfronthosting.co.za>


New submission from ayal baron <ayal.baron at rocketier.com>:

While running 2 or more threads, if one thread is importing anything
(i.e. has the import lock) and the other thread runs fork and then the
child process runs import then the child and parent will hang forever
(the child waits on the import lock but the parent receives the signal).
see Issue1590864 for another example of this.
Following is a simple way to reproduce this behavior:

mysleep.py:
import time
time.sleep(1)

run_me_and_hang.py:
import os
import threading
import subprocess
class F(threading.Thread):
	def run(self):
		import mysleep
		print "f is out"
f = F()
f.start()
a = subprocess.call(["echo", "DONE"])
print "exit"

----------
components: None
messages: 87044
nosy: abaron
severity: normal
status: open
title: import deadlocks when using fork
type: crash
versions: Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Sun May  3 15:45:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 May 2009 13:45:01 +0000
Subject: [New-bugs-announce] [issue5913] On Windows os.listdir('') -> cwd
	and os.listdir(u'') ->	C:\
In-Reply-To: <1241358301.45.0.540754079483.issue5913@psf.upfronthosting.co.za>
Message-ID: <1241358301.45.0.540754079483.issue5913@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

On Windows, with Python2/Python3, os.listdir('')/os.listdir(b'') list
the content of the current working directory and
os.listdir(u'')/os.listdir('') the content of C:\.

On Linux the error "OSError: [Errno 2] No such file or directory: ''" is
raised.

I also noticed that os.listdir('C:') (without the \) lists the content
of the cwd too.

----------
components: Library (Lib), Windows
messages: 87045
nosy: ezio.melotti
severity: normal
status: open
title: On Windows os.listdir('') -> cwd and os.listdir(u'') -> C:\
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun May  3 17:27:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 May 2009 15:27:15 +0000
Subject: [New-bugs-announce] [issue5914] Add PyOS_string_to_double function
	to C API
In-Reply-To: <1241364435.9.0.132810257571.issue5914@psf.upfronthosting.co.za>
Message-ID: <1241364435.9.0.132810257571.issue5914@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a patch that adds a PyOS_string_to_double function to complement 
the recently added PyOS_double_to_string function.

This is supposed to be a more Pythonic version of PyOS_ascii_strtod.  It 
raises Python exceptions to correspond to the various possible errors 
(malformed string, overflowing number, malloc failure...) instead of 
requiring the caller to examine errno.

It's intended for both internal and external use;  if this goes in, I 
intend to use it in the Python core in places where PyOS_ascii_strtod or 
PyOS_ascii_atof are currently used.

----------
assignee: marketdickinson
components: Interpreter Core
files: string_to_double.patch
keywords: patch
messages: 87048
nosy: eric.smith, marketdickinson
severity: normal
status: open
title: Add PyOS_string_to_double function to C API
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13852/string_to_double.patch

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 22:38:15 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 03 May 2009 20:38:15 +0000
Subject: [New-bugs-announce] [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>


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

This is the implementation of PEP 383. Rietveld submission will follow.

----------
assignee: benjamin.peterson
files: 383.diff
keywords: patch
messages: 87069
nosy: benjamin.peterson, loewis
priority: release blocker
severity: normal
status: open
title: PEP 383 implementation
Added file: http://bugs.python.org/file13857/383.diff

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

From report at bugs.python.org  Mon May  4 00:03:18 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sun, 03 May 2009 22:03:18 +0000
Subject: [New-bugs-announce] [issue5916] Wrong function referenced in
	documentation of	socket.inet_aton
In-Reply-To: <1241388198.89.0.66136453957.issue5916@psf.upfronthosting.co.za>
Message-ID: <1241388198.89.0.66136453957.issue5916@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister <phihag at phihag.de>:

>From the documentation of socket.inet_aton (and socket.inet_ntoa):

"inet_aton() does not support IPv6, and getnameinfo() should be used
instead for IPv4/v6 dual stack support."

socket.getnameinfo can not replace inet_aton/inet_ntoa at all. However,
inet_pton and inet_ntop can (and do support IPv6). Therefore, the
attached patch changes the getnameinfo references to inet_pton and
inet_ntop.

----------
assignee: georg.brandl
components: Documentation
files: aton-doc.diff
keywords: patch
messages: 87076
nosy: georg.brandl, phihag
severity: normal
status: open
title: Wrong function referenced in documentation of socket.inet_aton
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13858/aton-doc.diff

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

From report at bugs.python.org  Mon May  4 00:09:46 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sun, 03 May 2009 22:09:46 +0000
Subject: [New-bugs-announce] [issue5917] Reference platform-independent
	alternative in	socket.inet_ntop documentation
In-Reply-To: <1241388586.38.0.920530904266.issue5917@psf.upfronthosting.co.za>
Message-ID: <1241388586.38.0.920530904266.issue5917@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister <phihag at phihag.de>:

socket.inet_ntop is only available on some UNIX platforms, although for
example Windows users may want to use it. The new ipaddr module provides
a platform-independent conversion to the packed format on all platforms
and should therefore be used in platform-independent programs.

----------
assignee: georg.brandl
components: Documentation
files: doc-packed-ref.diff
keywords: patch
messages: 87078
nosy: georg.brandl, phihag
severity: normal
status: open
title: Reference platform-independent alternative in socket.inet_ntop documentation
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13859/doc-packed-ref.diff

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

From report at bugs.python.org  Mon May  4 02:01:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 00:01:14 +0000
Subject: [New-bugs-announce] [issue5918] test_parser crashes when run after
	test_distutils
In-Reply-To: <1241395274.73.0.21825310934.issue5918@psf.upfronthosting.co.za>
Message-ID: <1241395274.73.0.21825310934.issue5918@psf.upfronthosting.co.za>


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

This happens sometimes here on trunk, in non-debug mode:

$ ./python -m test.regrtest test_distutils test_parser
Could not find '/home/antoine/cpython/__svn__/Lib/test' in sys.path to
remove it
test_distutils
0 blocks
find:
`/home/antoine/tmp/tmpngdCYU/foo/build/bdist.linux-x86_64/rpm/BUILDROOT/foo-0.1-1.x86_64/usr/lib/debug':
Aucun fichier ou dossier de ce type
0 blocks
find:
`/home/antoine/tmp/tmp431p68/foo/build/bdist.linux-x86_64/rpm/BUILDROOT/foo-0.1-1.x86_64/usr/lib/debug':
Aucun fichier ou dossier de ce type
test_parser
Erreur de segmentation (core dumped)


Perhaps test_distutils sets something up which makes Python import the
wrong version of the "parser" module.

----------
assignee: tarek
components: Distutils, Tests
messages: 87087
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_parser crashes when run after test_distutils
type: crash
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon May  4 12:40:44 2009
From: report at bugs.python.org (Egon Frerich)
Date: Mon, 04 May 2009 10:40:44 +0000
Subject: [New-bugs-announce] [issue5919] pygettext documentation
In-Reply-To: <1241433644.84.0.826076454986.issue5919@psf.upfronthosting.co.za>
Message-ID: <1241433644.84.0.826076454986.issue5919@psf.upfronthosting.co.za>


New submission from Egon Frerich <e.frerich at nord-com.net>:

In 
23.1.3. Internationalizing your programs and modules
is shown how to get help-instructions for pygettext:
pygettext.py --help

As pygettext is a script the line should be:

pygettext --help

----------
messages: 87110
nosy: efrerich
severity: normal
status: open
title: pygettext documentation

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

From report at bugs.python.org  Mon May  4 13:10:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 May 2009 11:10:39 +0000
Subject: [New-bugs-announce] [issue5920] Confusing float formatting for
	empty presentation type.
In-Reply-To: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>
Message-ID: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I think the change in precision in the following is surprising, and should 
be fixed for 2.7 and 3.1:

Python 3.1a2+ (py3k:72258:72259, May  4 2009, 11:49:27) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{}'.format(10/3.)
'3.33333333333'
>>> '{:}'.format(10/3.)
'3.33333333333'
>>> '{:13}'.format(10/3.)
'      3.33333'
>>> '{:-}'.format(10/3.)
'3.33333'

Notice that the first two results above give 12 digits of precision,
while the third and fourth both give 6 digits of precision.

The above behaviour can be explained by a close reading of PEP 3101.
The last two results come from the section describing the empty 
presentation type for floats:

"""similar to 'g', except that it prints at least one digit after the 
decimal point."""

along with the fact that for 'g', the default precision is 6.  The first 
two results come from this sentence, at the end of the same section:

"""For all built-in types, an empty format specification will produce the 
equivalent of str(value)."""

and the fact that str(float) uses a precision of 12.

To me, it seems wrong, and potentially confusing, that adding a field 
width, or alignment specifier, or sign specifier, all of which have 
nothing to do with precision, should change the precision.

One possible solution would be to have the empty presentation type always 
use a precision of 12.  The output would still be 'similar to 'g'', except 
for the difference in default precision.

----------
assignee: eric.smith
messages: 87114
nosy: eric.smith, marketdickinson
severity: normal
stage: needs patch
status: open
title: Confusing float formatting for empty presentation type.
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon May  4 15:52:31 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 04 May 2009 13:52:31 +0000
Subject: [New-bugs-announce] [issue5921] PEP 362 can be marked as finished?
In-Reply-To: <1241445151.97.0.361648348921.issue5921@psf.upfronthosting.co.za>
Message-ID: <1241445151.97.0.361648348921.issue5921@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

It looks like PEP 362 has been implemented in the py3k branch:

>>> def f(x: int):
...   pass
...
>>>

----------
components: None
messages: 87125
nosy: stutzbach
severity: normal
status: open
title: PEP 362 can be marked as finished?
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon May  4 16:29:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 14:29:50 +0000
Subject: [New-bugs-announce] [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

So that this doesn't get overlooked.

----------
assignee: georg.brandl
components: Interpreter Core
files: issue53094_2001.diff
keywords: patch
messages: 87131
nosy: georg.brandl
priority: release blocker
severity: normal
stage: patch review
status: open
title: Multi-with patch
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13869/issue53094_2001.diff

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

From report at bugs.python.org  Mon May  4 16:56:38 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 04 May 2009 14:56:38 +0000
Subject: [New-bugs-announce] [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

I propose to update turtle.py with this new version 1.1 of the turtle
module. 

Summary of changes:

1. a few bugfixes, with 1 - 5 lines of code changed for each;
   these concern bugs that prevented turtle to run correctly

2. I've added four methods to the class TurtleScreeenBase:
   _onkeypress(fun, key)  (supplementing _onkeyrelease)
   mainloop()  (which is now a Screen-method and a function)
   textinput(title, prompt)
   numinput(title, prompt, default, minval, maxval)
          the latter two remedy the complete lack of input methods

   _onkey, an internal method name is changed to _onkeyrelease

3. I've added one method to the class TurtleScreen:
   onkeypress(fun, key=None)        implemented in analogy to the
already present onkey()
       which got onkeyrelease as an alias.

4. I've changed several portions of the code that affect
  the representation of the turtleshape thus making it
  more compact (by removing some duplicated code) and more
  powerful, i. e. by adding the possibility to apply
  shearings to turtleshapes (in addition to the already present
  scaling and rotating transformations). Thus now the full
  range of (non singular) linear transformations is available.

  New methods in class RawTurtle:
   shearfactor(shear=None)    set or get the shearfactor
   shapetransform(t11, t12, t21, t22)
                   set or get the shape transform directly
   get_shapepoly() return the polygon of the current shape

  I've enhanced the functionality of tiltangle(angle=None)
  to contain also that of settiltangle and I propose to
  declare settiltangle as deprecated.
  5. I've removed a lot of codelines that were commented out
  during the process of transferring the module from 2.6
  to 3.0

6. I've implemented the bugfix for http://bugs.python.org/issue4117
  according do my proposition there and I strongly
  recommend this change again, as the bug described is very
  annoying, the fix is easy and no one proposed a better
  solution. 

For convenience I'll add the diff subsequently

Regards,
Gregor

----------
components: Library (Lib)
files: turtle31.py
messages: 87132
nosy: benjamin.peterson, gregorlingl, loewis, rhettinger
severity: normal
status: open
title: turtle.py update: 1.0 --> 1.1
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13870/turtle31.py

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

From report at bugs.python.org  Mon May  4 21:06:10 2009
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 04 May 2009 19:06:10 +0000
Subject: [New-bugs-announce] [issue5924] When setting complete PYTHONPATH on
	Python 3.x, paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Setting the complete PYTHONPATH in Python 3.x does not work (reported
initially for Pydev:
https://sourceforge.net/tracker/index.php?func=detail&aid=2767830&group_id=85796&atid=577329
). Checked on 3.0.1 and 3.1a2.

I'm not sure if the paths must be the same, but when I did change the
path of the project, the bug was not always reproduced.

I've reproduced it on Windows XP SP3.

To reproduce, extract the ProjectStructure so that you have a path as
c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py

Then considering your python install is at d:\bin\Python301, set the
pythonpath as:

[C:\temp]set pythonpath=C:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src;C:\Documents
and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_a\src;D:\bin\Python301;D:\bin\Python301\DLLs;D:\bin\Python301\lib;D:\bin\Python301\lib\plat-win;D:\bin\Python301\lib\site-packages

And run the command below:

[C:\temp]d:\bin\Python301\python.exe "c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py"
Running code is 'c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py'

The contents of 'sys.path' is:
c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src
C:\WINDOWS\system32\python30.zip
D:\bin\Python301\DLLs
D:\bin\Python301\lib
D:\bin\Python301\lib\plat-win
D:\bin\Python301
D:\bin\Python301\lib\site-packages
Traceback (most recent call last):
  File "c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py",
line 11, in <module>
    from testmod_a import testfunc
ImportError: No module named testmod_a


Note how the module was not properly imported... Now, if the PYTHONPATH
is set without the system folders:

[C:\temp]set pythonpath=C:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src;C:\Documents
and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_a\src

Running the command line:

[C:\temp]d:\bin\Python301\python.exe "c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py"
Running code is 'c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py'

The contents of 'sys.path' is:
c:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src
C:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src
C:\Documents and
Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_a\src
C:\WINDOWS\system32\python30.zip
D:\bin\Python301\DLLs
D:\bin\Python301\lib
D:\bin\Python301\lib\plat-win
D:\bin\Python301
D:\bin\Python301\lib\site-packages

'test_print()' in "testmod_a.testfunc" is called.

Properly works. Note that on Python 2.x this works.

----------
components: Interpreter Core, Windows
files: ProjectStructure.zip
messages: 87151
nosy: fabioz
severity: normal
status: open
title: When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13874/ProjectStructure.zip

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

From report at bugs.python.org  Mon May  4 21:12:06 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 04 May 2009 19:12:06 +0000
Subject: [New-bugs-announce] [issue5925] Odd formatting differences of
	keywords in reference
In-Reply-To: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>
Message-ID: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the section at reference/lexical_analysis.html#keywords of the HTML
documentation some of the keywords are formatted differently from the
majority. In the HTML markup most of the keywords have CSS class 'k',
but others have 'n', 'nc', 'kn', 'nn', or 'ow'. I don't see any pattern
to which keywords are formatted which way, so I believe this should be
corrected. Or, if the differences are intentional they should be
documented. [Just trying to help clean up the doc -- I realize how
trivial this is.]

----------
assignee: georg.brandl
components: Documentation
messages: 87153
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Odd formatting differences of keywords in reference
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon May  4 21:29:44 2009
From: report at bugs.python.org (Anthony Tuininga)
Date: Mon, 04 May 2009 19:29:44 +0000
Subject: [New-bugs-announce] [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: <1241465384.5.0.639061880588.issue5926@psf.upfronthosting.co.za>


New submission from Anthony Tuininga <anthony.tuininga at gmail.com>:

Add support for specifying the minimum Python version supported so that
versions which are not supported are not included when running the MSI
created by distutils for pure Python packages with the patch referred to
here:

http://bugs.python.org/issue5311

----------
assignee: tarek
components: Distutils
messages: 87154
nosy: atuining, tarek
severity: normal
status: open
title: bdist_msi - add support for minimum Python version for pure Python packages
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon May  4 21:30:49 2009
From: report at bugs.python.org (Jonathan Hayward)
Date: Mon, 04 May 2009 19:30:49 +0000
Subject: [New-bugs-announce] [issue5927] Typo in library on xmlrpc
In-Reply-To: <1241465449.18.0.71964516838.issue5927@psf.upfronthosting.co.za>
Message-ID: <1241465449.18.0.71964516838.issue5927@psf.upfronthosting.co.za>


New submission from Jonathan Hayward <jonathan.hayward at pobox.com>:

On http://docs.python.org/library/xmlrpclib.html , 21.23.1, at the end
of ServerProxy.system.methodSignature(name):

If no signature is defined for the method, a non-array value is
returned. In Python this means that the type of the returned value will
be something other that list.

I assume this should be:

If no signature is defined for the method, a non-array value is
returned. In Python this means that the type of the returned value will
be something other than list.

reading 'thaN' for 'thaT' in the second-to-last word?

Jonathan
http://JonathansCorner.com

----------
assignee: georg.brandl
components: Documentation
messages: 87156
nosy: JonathansCorner.com, georg.brandl
severity: normal
status: open
title: Typo in library on xmlrpc

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

From report at bugs.python.org  Mon May  4 21:35:24 2009
From: report at bugs.python.org (Jonathan Hayward)
Date: Mon, 04 May 2009 19:35:24 +0000
Subject: [New-bugs-announce] [issue5928] Missing space after period in
	xmlrpc library documentation
In-Reply-To: <1241465724.43.0.0907945517424.issue5928@psf.upfronthosting.co.za>
Message-ID: <1241465724.43.0.0907945517424.issue5928@psf.upfronthosting.co.za>


New submission from Jonathan Hayward <jonathan.hayward at pobox.com>:

Under http://docs.python.org/library/xmlrpclib.html , 21.23.1:

ServerProxy.system.methodSignature(name)?
This method takes one parameter, the name of a method implemented by the
XML-RPC server.It

There should be a space before the second sentence in this paragraph.

Jonathan
http://JonathansCorner.com/

----------
assignee: georg.brandl
components: Documentation
messages: 87158
nosy: JonathansCorner.com, georg.brandl
severity: normal
status: open
title: Missing space after period in xmlrpc library documentation

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

From report at bugs.python.org  Mon May  4 23:19:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 21:19:44 +0000
Subject: [New-bugs-announce] [issue5929] warnings in unicodeobject.c
In-Reply-To: <1241471984.38.0.629165651033.issue5929@psf.upfronthosting.co.za>
Message-ID: <1241471984.38.0.629165651033.issue5929@psf.upfronthosting.co.za>


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

This happens in trunk and py3k:

gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o
Objects/unicodeobject.o Objects/unicodeobject.c
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_FromFormatV?:
Objects/unicodeobject.c:795: attention : pointer targets in passing
argument 1 of ?strlen? differ in signedness
Objects/unicodeobject.c:795: attention : pointer targets in passing
argument 1 of ?PyUnicodeUCS2_DecodeUTF8? differ in signedness

----------
components: Interpreter Core
messages: 87180
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: warnings in unicodeobject.c
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon May  4 23:33:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 21:33:24 +0000
Subject: [New-bugs-announce] [issue5930] Transient error in multiprocessing
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>


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

Just got this on py3k, I can't reproduce unfortunately.

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 1070, in test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 10 != 1

----------
assignee: jnoller
components: Library (Lib)
messages: 87182
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Transient error in multiprocessing
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue May  5 01:11:05 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Mon, 04 May 2009 23:11:05 +0000
Subject: [New-bugs-announce] [issue5931] Python runtime name hardcoded in
	wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>


New submission from Thijs Triemstra <lists at collab.nl>:

While testing the following script on Jython 2.5b4 I noticed it returned 
SERVER_SOFTWARE = 'WSGIServer/0.1 Python/2.5b4+' instead of the expected 
'WSGIServer/0.1 Jython/2.5b4+'. This is because the word 'Python' is 
hardcoded in simple_server.py; "sys_version = "Python/" + 
sys.version.split()[0]". I suggest using the real name of the runtime 
instead of hardcoding it.

from wsgiref.simple_server import make_server, demo_app

httpd = make_server('', 8000, demo_app)
print "Serving HTTP on port 8000..."

# Respond to requests until process is killed
httpd.serve_forever()

# Alternative: serve one request, then exit
httpd.handle_request()

----------
components: Library (Lib)
messages: 87190
nosy: thijs
severity: normal
status: open
title: Python runtime name hardcoded in wsgiref.simple_server
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue May  5 02:21:53 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2009 00:21:53 +0000
Subject: [New-bugs-announce] [issue5932] _json: _convertPyInt_AsSsize_t()
	never raise any error
In-Reply-To: <1241482913.08.0.841842039373.issue5932@psf.upfronthosting.co.za>
Message-ID: <1241482913.08.0.841842039373.issue5932@psf.upfronthosting.co.za>


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

_convertPyInt_AsSsize_t() always return 1 (success) even on 
PyInt_AsSsize_t() error because of a ";" after the if...

    if (*size_ptr == -1 && PyErr_Occurred());
        return 1;

Attached patch fixes this issue, and add a regression test.

----------
components: Library (Lib)
files: json_error.patch
keywords: patch
messages: 87191
nosy: haypo
severity: normal
status: open
title: _json: _convertPyInt_AsSsize_t() never raise any error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13882/json_error.patch

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

From report at bugs.python.org  Tue May  5 02:24:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2009 00:24:59 +0000
Subject: [New-bugs-announce] [issue5933] fix gcc -Wextra warnings (compare
	signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>


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

Simple patch to fix some gcc warnings (when using gcc -Wall -Wextra).

----------
components: Library (Lib)
files: sign_warning.patch
keywords: patch
messages: 87192
nosy: haypo
severity: normal
status: open
title: fix gcc -Wextra warnings (compare signed/unsigned)
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13883/sign_warning.patch

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

From report at bugs.python.org  Tue May  5 02:44:18 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2009 00:44:18 +0000
Subject: [New-bugs-announce] [issue5934] fix gcc warnings: explicit type
	conversion for uid/gid in	posix
In-Reply-To: <1241484258.44.0.246331146842.issue5934@psf.upfronthosting.co.za>
Message-ID: <1241484258.44.0.246331146842.issue5934@psf.upfronthosting.co.za>


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

Explicit type conversion to fix gcc -Wextra warnings. The patch 
doesn't change the behaviour, it just makes gcc quiet.

----------
components: Library (Lib)
files: posix_warnings.patch
keywords: patch
messages: 87196
nosy: haypo
severity: normal
status: open
title: fix gcc warnings: explicit type conversion for uid/gid in posix
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13887/posix_warnings.patch

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

From report at bugs.python.org  Tue May  5 04:13:50 2009
From: report at bugs.python.org (Edmund Eyles)
Date: Tue, 05 May 2009 02:13:50 +0000
Subject: [New-bugs-announce] [issue5935] Better documentation of use of
	BROWSER environment	variable
In-Reply-To: <1241489630.51.0.91257880678.issue5935@psf.upfronthosting.co.za>
Message-ID: <1241489630.51.0.91257880678.issue5935@psf.upfronthosting.co.za>


New submission from Edmund Eyles <hotel at heddonsgate.co.uk>:

The documentation for the webbrowser module at
http://www.python.org/doc/2.5/lib/module-webbrowser.html refers to the
use of the BROWSER environment variable as a means to control which
browser is run.  However, it makes no mention of how the browser name(s)
in this environment variable get translated into executables,
particularly the process by which the only directories to be searched
are those in the PATH environment variable.  

For instance, on my Windows PC where the default browser is IE, simply
setting BROWSER to 'firefox' has no effect.  I also need to add
'C:\Program Files\Mozilla Firefox' to PATH, after which Firefox actually
gets run.

----------
assignee: georg.brandl
components: Documentation
messages: 87200
nosy: Eddie E, georg.brandl
severity: normal
status: open
title: Better documentation of use of BROWSER environment variable
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Tue May  5 04:30:01 2009
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 05 May 2009 02:30:01 +0000
Subject: [New-bugs-announce] [issue5936] Add MSI suport for uninstalling
	individual versions
In-Reply-To: <1241490601.47.0.970158126843.issue5936@psf.upfronthosting.co.za>
Message-ID: <1241490601.47.0.970158126843.issue5936@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

With issue5311 now resolved, bdist_msi can generate a single MSI that
can install to any number of Python versions (for pure Python modules).
Right now, you can only install or uninstall these MSIs, but it would be
nice to also provide a "Change" installation.

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.

I'll try to make some time to work on this.

----------
assignee: bethard
messages: 87203
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: Add MSI suport for uninstalling individual versions
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue May  5 06:19:18 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 05 May 2009 04:19:18 +0000
Subject: [New-bugs-announce] [issue5937] Problems with dbm documentation
In-Reply-To: <1241497158.05.0.293072104971.issue5937@psf.upfronthosting.co.za>
Message-ID: <1241497158.05.0.293072104971.issue5937@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

There are some problems with the dbm documentation. In the opening section:

1.  The comment before the iteration example says that .values() works,
but the method is not defined.
2.  The statement in the paragraph after the documentation of dbm.open()
says that the opened dbm object "supports most of the same functionality
as dictionaries". It specifically mentions keys(), but should state that
values() is not supported.
3.  I disagree with the use of the word "most" there. It does support a
minimal dictionary-like interface, but it provides only about 1/3 of the
method that dict does.
4.  The documentation should point out that keys() returns a list not a
dict_keys object.
5.  The example code shows the use of iteritems() but the documentation
doesn't mention it. In any case, there is no such method.
6.  In fact, the comment at the beginning of dbm/__init__.py states that
the interface is limited to set, get, and del using [] notation, the in
operator (and though not stated, the not in operator), and k.keys().

The Unix dbm section does state that values() and items() are not
supported, but the gdbm section does not (and should).

I hope this is all accurate. In general, the whole page should be edited
to be consistent with the actual implementation.

----------
assignee: georg.brandl
components: Documentation
messages: 87208
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Problems with dbm documentation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue May  5 09:37:28 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 07:37:28 +0000
Subject: [New-bugs-announce] [issue5938] Noddy examples haven't been updated
	to match PEP 3123
In-Reply-To: <1241509048.45.0.629078004915.issue5938@psf.upfronthosting.co.za>
Message-ID: <1241509048.45.0.629078004915.issue5938@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

The changes in PEP 3123 require that all type objects be statically
declared with PyVarObject_HEAD_INIT.  However, the Noddy examples in
Doc/ still use PyObject_HEAD_INIT.

----------
assignee: georg.brandl
components: Documentation
messages: 87214
nosy: benjamin.peterson, georg.brandl, larry
severity: normal
status: open
title: Noddy examples haven't been updated to match PEP 3123
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue May  5 09:40:48 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 07:40:48 +0000
Subject: [New-bugs-announce] [issue5939] Ensure that PyCapsule_GetPointer
	calls in ctypes handle	errors appropriately
In-Reply-To: <1241509248.29.0.789883637669.issue5939@psf.upfronthosting.co.za>
Message-ID: <1241509248.29.0.789883637669.issue5939@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

If my patch in issue 53046 is accepted, I hereby agree to figure out if
the calls to PyCapsule_GetPointer() in Modules/_ctypes/callproc.c need
more error checking or what.

----------
components: Interpreter Core
messages: 87215
nosy: benjamin.peterson, larry
severity: normal
status: open
title: Ensure that PyCapsule_GetPointer calls in ctypes handle errors appropriately
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue May  5 10:27:49 2009
From: report at bugs.python.org (Cournapeau David)
Date: Tue, 05 May 2009 08:27:49 +0000
Subject: [New-bugs-announce] [issue5940] Wrong type check in
	check_library_list
In-Reply-To: <1241512069.38.0.233347773971.issue5940@psf.upfronthosting.co.za>
Message-ID: <1241512069.38.0.233347773971.issue5940@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

There is a bug in the function check_library_list. Assuming there are
some libraries in the distribution instance, the function checks that
lib[0] is a string, but the test checks exactly the contrary (line 137
of build_clib.py).

This is pretty serious, as any code using libraries will fail to build
on python3. The fix is trivial, though. I think this should be fixed for
python 3.1

----------
assignee: tarek
components: Distutils
messages: 87224
nosy: cdavid, tarek
severity: normal
status: open
title: Wrong type check in check_library_list
versions: Python 3.1

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

From report at bugs.python.org  Tue May  5 11:09:22 2009
From: report at bugs.python.org (Cournapeau David)
Date: Tue, 05 May 2009 09:09:22 +0000
Subject: [New-bugs-announce] [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

The customize_compiler function is broken in python 3.1. The archiver
for a 'standard' unix compiler is set as ['ar', '-cr'], but in python
3.*, customize_compiler overwrites self.archiver from
get_sysconfig_var('AR'), and AR is defined as ar, which breaks
create_static_library.

I think the solution is to define a new env variable AR_something or to
set AR to 'ar -rc' (like LDSHARED is set to ['gcc', '-shared'] on gnu
systems, for example).

----------
assignee: tarek
components: Distutils
messages: 87231
nosy: cdavid, tarek
severity: normal
status: open
title: customize_compiler broken
versions: Python 3.1

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

From report at bugs.python.org  Tue May  5 15:58:24 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 05 May 2009 13:58:24 +0000
Subject: [New-bugs-announce] [issue5942] Ambiguity in dbm.open flag
	documentation
In-Reply-To: <1241531904.72.0.756438187813.issue5942@psf.upfronthosting.co.za>
Message-ID: <1241531904.72.0.756438187813.issue5942@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

It isn't clear from the explanation of dbm.open's flag values at the
beginning of the dbm documentation page whether 'c' and 'n' open the
database just for writing or for reading and writing. I'm sure it's
obvious to anyone familiar with dbm, and the example demonstrates that
'c' opens the database for reading and writing, but I think it's worth
making it explicit by adding a few words to the paragraph describing the
flags.

----------
assignee: georg.brandl
components: Documentation
messages: 87243
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Ambiguity in dbm.open flag documentation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue May  5 16:12:31 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 14:12:31 +0000
Subject: [New-bugs-announce] [issue5943] Bus error in test_posix on Mac OS
In-Reply-To: <1241532751.75.0.224602720021.issue5943@psf.upfronthosting.co.za>
Message-ID: <1241532751.75.0.224602720021.issue5943@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

I get a bus error in test_lchflags in test_posix.py on my Mac OS X 10.5 box.

I'll try and spend some time later today to debug this, but here's the
backtrace if anyone wants to look at it:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
bytes2str (o=0x0, lock=1) at posixmodule.c:545
545             if(PyBytes_Check(o))
(gdb) bt
#0  bytes2str (o=0x0, lock=1) at posixmodule.c:545
#1  0x000e5d3c in posix_lchflags (self=0x353a08, args=0x0) at
posixmodule.c:1986
#2  0x000a6037 in PyEval_EvalFrameEx (f=0x25ff30, throwflag=0) at
Python/ceval.c:3744
#3  0x000a6e42 in PyEval_EvalFrameEx (f=0x25c4f0, throwflag=0) at
Python/ceval.c:3832
#4  0x000a78cb in PyEval_EvalCodeEx (co=0x624380, globals=0x601420,
locals=0x0, args=0x69c154, argcount=2, kws=0x255410, kwcount=0,
defs=0x4ae4bc, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#5  0x00033cc5 in function_call (func=0x4b1660, arg=0x69c148,
kw=0x6a8ed0) at Objects/funcobject.c:628
#6  0x000085c9 in PyObject_Call (func=0x4b1660, arg=0x69c148,
kw=0x6a8ed0) at Objects/abstract.c:2161
#7  0x000a352b in PyEval_EvalFrameEx (f=0x25c380, throwflag=0) at
Python/ceval.c:4045
#8  0x000a78cb in PyEval_EvalCodeEx (co=0x6243c8, globals=0x601420,
locals=0x0, args=0x690dac, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#9  0x00033cc5 in function_call (func=0x4b16a8, arg=0x690da0, kw=0x0) at
Objects/funcobject.c:628
#10 0x000085c9 in PyObject_Call (func=0x4b16a8, arg=0x690da0, kw=0x0) at
Objects/abstract.c:2161
#11 0x0001ecfe in method_call (func=0x4b16a8, arg=0x69af70, kw=0x0) at
Objects/classobject.c:323
#12 0x000085c9 in PyObject_Call (func=0x45dc88, arg=0x69af70, kw=0x0) at
Objects/abstract.c:2161
#13 0x0005cec7 in slot_tp_call (self=0x0, args=0x69af70, kwds=0x0) at
Objects/typeobject.c:4956
#14 0x000085c9 in PyObject_Call (func=0x6a37d0, arg=0x69af70, kw=0x0) at
Objects/abstract.c:2161
#15 0x000a4ef8 in PyEval_EvalFrameEx (f=0x25c210, throwflag=0) at
Python/ceval.c:3957
#16 0x000a6e42 in PyEval_EvalFrameEx (f=0x25c090, throwflag=0) at
Python/ceval.c:3832
#17 0x000a78cb in PyEval_EvalCodeEx (co=0x62e7b8, globals=0x601420,
locals=0x0, args=0x690d84, argcount=2, kws=0x203e10, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x4aeab0) at Python/ceval.c:3180
#18 0x00033cc5 in function_call (func=0x4b56f0, arg=0x690d78,
kw=0x6a8e40) at Objects/funcobject.c:628
#19 0x000085c9 in PyObject_Call (func=0x4b56f0, arg=0x690d78,
kw=0x6a8e40) at Objects/abstract.c:2161
#20 0x000a352b in PyEval_EvalFrameEx (f=0x25bf20, throwflag=0) at
Python/ceval.c:4045
#21 0x000a78cb in PyEval_EvalCodeEx (co=0x62e608, globals=0x601420,
locals=0x0, args=0x69cf14, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#22 0x00033cc5 in function_call (func=0x4b55d0, arg=0x69cf08, kw=0x0) at
Objects/funcobject.c:628
#23 0x000085c9 in PyObject_Call (func=0x4b55d0, arg=0x69cf08, kw=0x0) at
Objects/abstract.c:2161
#24 0x0001ecfe in method_call (func=0x4b55d0, arg=0x69ad30, kw=0x0) at
Objects/classobject.c:323
#25 0x000085c9 in PyObject_Call (func=0x45db48, arg=0x69ad30, kw=0x0) at
Objects/abstract.c:2161
#26 0x0005cec7 in slot_tp_call (self=0x0, args=0x69ad30, kwds=0x0) at
Objects/typeobject.c:4956
#27 0x000085c9 in PyObject_Call (func=0x69afb0, arg=0x69ad30, kw=0x0) at
Objects/abstract.c:2161
#28 0x000a4ef8 in PyEval_EvalFrameEx (f=0x25bc50, throwflag=0) at
Python/ceval.c:3957
#29 0x000a78cb in PyEval_EvalCodeEx (co=0x62e5c0, globals=0x601420,
locals=0x0, args=0x690d34, argcount=2, kws=0x203e00, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#30 0x00033cc5 in function_call (func=0x4b5588, arg=0x690d28,
kw=0x6a8db0) at Objects/funcobject.c:628
#31 0x000085c9 in PyObject_Call (func=0x4b5588, arg=0x690d28,
kw=0x6a8db0) at Objects/abstract.c:2161
#32 0x000a352b in PyEval_EvalFrameEx (f=0x25bae0, throwflag=0) at
Python/ceval.c:4045
#33 0x000a78cb in PyEval_EvalCodeEx (co=0x62e608, globals=0x601420,
locals=0x0, args=0x690d5c, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#34 0x00033cc5 in function_call (func=0x4b55d0, arg=0x690d50, kw=0x0) at
Objects/funcobject.c:628
#35 0x000085c9 in PyObject_Call (func=0x4b55d0, arg=0x690d50, kw=0x0) at
Objects/abstract.c:2161
#36 0x0001ecfe in method_call (func=0x4b55d0, arg=0x69a910, kw=0x0) at
Objects/classobject.c:323
#37 0x000085c9 in PyObject_Call (func=0x45dbe8, arg=0x69a910, kw=0x0) at
Objects/abstract.c:2161
#38 0x0005cec7 in slot_tp_call (self=0x0, args=0x69a910, kwds=0x0) at
Objects/typeobject.c:4956
#39 0x000085c9 in PyObject_Call (func=0x69acd0, arg=0x69a910, kw=0x0) at
Objects/abstract.c:2161
#40 0x000a4ef8 in PyEval_EvalFrameEx (f=0x25b390, throwflag=0) at
Python/ceval.c:3957
#41 0x000a6e42 in PyEval_EvalFrameEx (f=0x25a390, throwflag=0) at
Python/ceval.c:3832
#42 0x000a6e42 in PyEval_EvalFrameEx (f=0x2594b0, throwflag=0) at
Python/ceval.c:3832
#43 0x000a78cb in PyEval_EvalCodeEx (co=0x4641d0, globals=0x4ca9c0,
locals=0x0, args=0x257fbc, argcount=1, kws=0x257fc0, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#44 0x000a5dfb in PyEval_EvalFrameEx (f=0x257e80, throwflag=0) at
Python/ceval.c:3842
#45 0x000a6e42 in PyEval_EvalFrameEx (f=0x2579a0, throwflag=0) at
Python/ceval.c:3832
#46 0x000a78cb in PyEval_EvalCodeEx (co=0x420968, globals=0x34d0c0,
locals=0x0, args=0x25794c, argcount=7, kws=0x257968, kwcount=0,
defs=0x4d23fc, defcount=3, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#47 0x000a5dfb in PyEval_EvalFrameEx (f=0x2577f0, throwflag=0) at
Python/ceval.c:3842
#48 0x000a78cb in PyEval_EvalCodeEx (co=0x4209f8, globals=0x34d0c0,
locals=0x0, args=0x914838, argcount=7, kws=0x914854, kwcount=0,
defs=0x4ccba4, defcount=3, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#49 0x000a5dfb in PyEval_EvalFrameEx (f=0x914610, throwflag=0) at
Python/ceval.c:3842
#50 0x000a78cb in PyEval_EvalCodeEx (co=0x392188, globals=0x34d0c0,
locals=0x0, args=0x21895c, argcount=0, kws=0x21895c, kwcount=0,
defs=0x48685c, defcount=18, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#51 0x000a5dfb in PyEval_EvalFrameEx (f=0x218820, throwflag=0) at
Python/ceval.c:3842
#52 0x000a78cb in PyEval_EvalCodeEx (co=0x43d068, globals=0x34d0c0,
locals=0x34d0c0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3180
#53 0x000a7a9f in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at
Python/ceval.c:650
#54 0x000ccdd0 in PyRun_FileExFlags (fp=0xa05324c0, filename=0x448120
"Lib/test/regrtest.py", start=257, globals=0x34d0c0, locals=0x34d0c0,
closeit=1, flags=0xbffff52c) at Python/pythonrun.c:1697
#55 0x000cdc43 in PyRun_SimpleFileExFlags (fp=<value temporarily
unavailable, due to optimizations>, filename=0x448120
"Lib/test/regrtest.py", closeit=1, flags=0xbffff52c) at
Python/pythonrun.c:1182
#56 0x000dd140 in Py_Main (argc=4, argv=0x2000f0) at Modules/main.c:625
#57 0x00002799 in main (argc=4, argv=0xbffff690) at python.c:136
(gdb)

----------
components: Extension Modules
messages: 87244
nosy: eric.smith
priority: release blocker
severity: normal
status: open
title: Bus error in test_posix on Mac OS
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue May  5 20:01:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 18:01:18 +0000
Subject: [New-bugs-announce] [issue5944] test_os failure on OS X,
	probably related to PEP 383
In-Reply-To: <1241546478.3.0.733152091309.issue5944@psf.upfronthosting.co.za>
Message-ID: <1241546478.3.0.733152091309.issue5944@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I'm getting what looks like a PEP 383-related failure in test_os, on OS 
X 10.5.6.  Here's the tail end of running Lib/test/test_os.py, on a
standard non-debug build of py3k.

test_setuid (__main__.PosixUidGidTests) ... ok
test_listdir (__main__.Pep383Tests) ... FAIL
test_open (__main__.Pep383Tests) ... ok
test_stat (__main__.Pep383Tests) ... ok

======================================================================
FAIL: test_listdir (__main__.Pep383Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_os.py", line 725, in test_listdir
    self.assertEquals(found, expected)
AssertionError: Items in the first set but not the second:
'foo?bar'
'foo%F6bar'
Items in the second set but not the first:
'foo\udcf6bar'
'foo?bar'

----------------------------------------------------------------------
Ran 60 tests in 0.079s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_os.py", line 758, in <module>
    test_main()
  File "Lib/test/test_os.py", line 754, in test_main
    Pep383Tests
  File "/Users/dickinsm/svn/python/py3k/Lib/test/support.py", line 878, 
in run_unittest
    _run_suite(suite)
  File "/Users/dickinsm/svn/python/py3k/Lib/test/support.py", line 861, 
in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_os.py", line 725, in test_listdir
    self.assertEquals(found, expected)
AssertionError: Items in the first set but not the second:
'foo?bar'
'foo%F6bar'
Items in the second set but not the first:
'foo\udcf6bar'
'foo?bar'

----------
messages: 87264
nosy: loewis, marketdickinson
priority: critical
severity: normal
status: open
title: test_os failure on OS X, probably related to PEP 383
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue May  5 23:47:16 2009
From: report at bugs.python.org (John Millikin)
Date: Tue, 05 May 2009 21:47:16 +0000
Subject: [New-bugs-announce] [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

In Python 2, PyMapping_Check will return 0 for list objects. In Python
3, it returns 1. Obviously, this makes it rather difficult to
differentiate between mappings and other sized iterables. In addition,
it differs from the behavior of the ``collections.Mapping`` ABC --
isinstance([], collections.Mapping) returns False.

Since most of the PyMapping_* functions don't seem to work properly on
lists, I believe this behavior is erroneous.

The behavior can be seen from a C extension, or if you're lazy, using
ctypes:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('libpython2.6.so').PyMapping_Check(ctypes.py_object([]))
0

Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('libpython3.0.so').PyMapping_Check(ctypes.py_object([]))
1

----------
components: Library (Lib)
messages: 87291
nosy: jmillikin
severity: normal
status: open
title: PyMapping_Check returns 1 for lists
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed May  6 01:23:56 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 23:23:56 +0000
Subject: [New-bugs-announce] [issue5946] Fix spelling error in Capsule docs
In-Reply-To: <1241565836.19.0.75151730521.issue5946@psf.upfronthosting.co.za>
Message-ID: <1241565836.19.0.75151730521.issue5946@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

In the comments for the Capsule patch:
  http://bugs.python.org/issue5630 
dalcinl correctly pointed out that I had misspelled "disambiguate",
which I missed.  This patch fixes that mistake.

----------
assignee: georg.brandl
components: Documentation
files: lch.capsuledoc.r72363.diff
keywords: patch
messages: 87301
nosy: dalcinl, georg.brandl, larry
severity: normal
status: open
title: Fix spelling error in Capsule docs
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13900/lch.capsuledoc.r72363.diff

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

From report at bugs.python.org  Wed May  6 01:45:33 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 23:45:33 +0000
Subject: [New-bugs-announce] [issue5947] Deprecate CObject
In-Reply-To: <1241567133.24.0.131826723063.issue5947@psf.upfronthosting.co.za>
Message-ID: <1241567133.24.0.131826723063.issue5947@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

With the Capsule API patch accepted, I'd like to officially deprecate
CObject.  This patch causes Python to emit a single runtime warning the
first time a CObject is constructed in a particular Python instance.  If
those aren't the right semantics for a deprecation warning, please let
me know and I'll fix it.

----------
components: Interpreter Core
files: lch.deprecatecobject.r72363.diff
keywords: patch
messages: 87302
nosy: larry
severity: normal
status: open
title: Deprecate CObject
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13901/lch.deprecatecobject.r72363.diff

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

From report at bugs.python.org  Wed May  6 15:22:55 2009
From: report at bugs.python.org (Kerfred)
Date: Wed, 06 May 2009 13:22:55 +0000
Subject: [New-bugs-announce] [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>


New submission from Kerfred <fgilles at index-education.fr>:

There is a regression bug between Python 2.5 and Python 2.6.

With Python 2.5, the following code works:
import locale
locale.setlocale(locale.LC_ALL, 'fr')

Whereas with Python 2.6, I get this message:
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\Lib\locale.py", line 513, in setlocale
    return _setlocale(category, locale)
Error: unsupported locale setting

I am using Python 2.6.2 on Windows XP 32 bits.

Regards,
Fred
--

----------
components: Library (Lib)
messages: 87331
nosy: Kerfred
severity: normal
status: open
title: setlocale regression
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed May  6 17:45:41 2009
From: report at bugs.python.org (Kevin Watters)
Date: Wed, 06 May 2009 15:45:41 +0000
Subject: [New-bugs-announce] [issue5949] IMAP4_SSL spin because of
	SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>


New submission from Kevin Watters <kevinwatters at gmail.com>:

I cannot reproduce this locally yet, but I have several bug reports from users showing 
that IMAP4_SSL connections can get stuck in an infinite loop during logout()

  File "imaplib.pyo", line 529, in logout
  File "imaplib.pyo", line 1059, in _simple_command
  File "imaplib.pyo", line 889, in _command_complete
  File "imaplib.pyo", line 990, in _get_tagged_response
  File "imaplib.pyo", line 907, in _get_response
  File "imaplib.pyo", line 1000, in _get_line
  File "imaplib.pyo", line 1170, in readline
  File "ssl.pyo", line 136, in read

IMAP4_SSL uses ssl.wrap_socket and should probably be passing 
suppress_ragged_eofs=False. Without this, self.sslobj.read() may return '' forever, and 
both IMAP4_SSL.read() and IMAP4_SSL.readline() will spin. With 
suppress_ragged_eofs=False, calling logout() may raise an SSLError instead.

Thoughts?

----------
components: Library (Lib)
messages: 87337
nosy: kevinwatters
severity: normal
status: open
title: IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed May  6 18:49:46 2009
From: report at bugs.python.org (Dmitry)
Date: Wed, 06 May 2009 16:49:46 +0000
Subject: [New-bugs-announce] [issue5950] zimport doesn't work with zipfile
	containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>


New submission from Dmitry <dms at samersoff.net>:

Synopsys:
zimport not able to import a module from zipfile if zipfile contains
comment.
Versions:
This is Zip 2.32 (June 19th 2006), by Info-ZIP
Python 2.5.2 or 2.6.2

Steps to reproduce:
create a module, create an app that imports this module.
zip the module, make sure it works. 
Run: echo "Some comments" | zip -z module.zip
the app stop working.

----------
components: Interpreter Core
files: testcase.zip
messages: 87340
nosy: dsamersoff
severity: normal
status: open
title: zimport doesn't work with zipfile containing comments
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file13905/testcase.zip

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

From report at bugs.python.org  Thu May  7 01:45:21 2009
From: report at bugs.python.org (jal)
Date: Wed, 06 May 2009 23:45:21 +0000
Subject: [New-bugs-announce] [issue5951] email.message : get_payload args's
	documentation is	confusing
In-Reply-To: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>
Message-ID: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>


New submission from jal <loic.jaquemet+python at gmail.com>:

>From documentation : 
http://docs.python.org/library/email.message.html?highlight=email#email.message.Message.get_payload

get_payload([i[, decode]])

"With optional argument i,[..] If the payload is a string (i.e.
is_multipart() is False) and i is given, a TypeError is raised."

and 

"Optional decode is a flag [..] When True and the message is not a
multipart, the payload will be decoded if this header?s value is
quoted-printable or base64. [..]"

Now the bug : 
On a non-multipart b64 email,
how can the second-level-option "decode" be used, when using
first-level-optional 'i' throws an exception...

Two fixes possible : 
a) code fix
b) documentation fix

----------
assignee: georg.brandl
components: Documentation
messages: 87353
nosy: georg.brandl, trolldbois
severity: normal
status: open
title: email.message : get_payload args's documentation is confusing
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May  7 04:12:41 2009
From: report at bugs.python.org (Sergey Prigogin)
Date: Thu, 07 May 2009 02:12:41 +0000
Subject: [New-bugs-announce] [issue5952] AttributeError exception in
	urllib.urlopen
In-Reply-To: <1241662361.32.0.52605331473.issue5952@psf.upfronthosting.co.za>
Message-ID: <1241662361.32.0.52605331473.issue5952@psf.upfronthosting.co.za>


New submission from Sergey Prigogin <sprigogin at google.com>:

File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 82, in
urlopen
   return opener.open(url)
  File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 190, in open
   return getattr(self, name)(url)
  File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 322, in
open_http
   return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 339, in
http_error
   return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 579, in
http_error_default
   return addinfourl(fp, headers, "http:" + url)
  File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 871, in
__init__
   addbase.__init__(self, fp)
  File "/usr/grte/v1/piii-linux/lib/python2.4/urllib.py", line 818, in
__init__
   self.read = self.fp.read
 AttributeError: 'NoneType' object has no attribute 'read'

----------
components: Library (Lib)
messages: 87356
nosy: sprigogin
severity: normal
status: open
title: AttributeError exception in urllib.urlopen
type: crash
versions: Python 2.4

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

From report at bugs.python.org  Thu May  7 05:19:24 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 07 May 2009 03:19:24 +0000
Subject: [New-bugs-announce] [issue5953] Add to "whats new": range(n) !=
	range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I just discovered to my (deep) surprise that
        range(n) != range(n)
I think that's worth including in the what's new document.
I realize that the document essentially says that in python 3 range
behaves the way xrange did in python 2 and that ranges have very little
behavior, but surely the lack of equality of two ranges whose string
representations are equal is enough of a surprise and difference from
python 2 to be worth an explicit comment. (Or maybe no-one ever compares
ranges? They are just for iteration? Even that should be said
explicitly. This is one of those things that I'm sure expert developers
look at and think is obvious but might trip up ordinary users.)

----------
assignee: georg.brandl
components: Documentation
messages: 87357
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Add to "whats new": range(n) != range(n)
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu May  7 09:02:44 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 07 May 2009 07:02:44 +0000
Subject: [New-bugs-announce] [issue5954] PyFrame_GetLineNumber
In-Reply-To: <1241679764.04.0.154044942183.issue5954@psf.upfronthosting.co.za>
Message-ID: <1241679764.04.0.154044942183.issue5954@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to
get the line number of a specified frame, but there's no way to do that
directly. Forcing people to go through the code object makes them know
more about the guts of the interpreter than they should need. The
proposed PyFrame_GetLineNumber provides a more obvious and direct way to
do the same thing.

If this goes in, we might be able to deprecate PyCode_Addr2Line
entirely. The uses of PyCode_Addr2Line that don't get the line of a
particular frame seem to be getting the line from a traceback (for
example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field.

----------
components: Interpreter Core
files: PyFrame_GetLineNumber.patch
keywords: needs review, patch
messages: 87360
nosy: collinwinter, jyasskin
severity: normal
stage: patch review
status: open
title: PyFrame_GetLineNumber
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file13909/PyFrame_GetLineNumber.patch

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

From report at bugs.python.org  Thu May  7 12:02:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 10:02:37 +0000
Subject: [New-bugs-announce] [issue5955] aifc: close() does not close the
	underlying file
In-Reply-To: <1241690557.41.0.153347725808.issue5955@psf.upfronthosting.co.za>
Message-ID: <1241690557.41.0.153347725808.issue5955@psf.upfronthosting.co.za>


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

Seen on Windows buildbot:
'test_aifc' left behind file '@test' and it couldn't be removed: [Error
32] The process cannot access the file because it is being used by
another process: '@test'

This is because Aifc_read.close() does not close the underlying file.

----------
assignee: r.david.murray
messages: 87365
nosy: amaury.forgeotdarc, benjamin.peterson, r.david.murray
severity: normal
status: open
title: aifc: close() does not close the underlying file

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

From report at bugs.python.org  Thu May  7 19:13:17 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Thu, 07 May 2009 17:13:17 +0000
Subject: [New-bugs-announce] [issue5956] test_distutils fails for Python
	3.1b1 on MacOS X
In-Reply-To: <1241716397.0.0.0306627800748.issue5956@psf.upfronthosting.co.za>
Message-ID: <1241716397.0.0.0306627800748.issue5956@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

% make test
....
test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "../Python-3.1b1/Lib/distutils/tests/test_bdist_wininst.py", line 
23, in test_get_exe_bytes
    exe_file = cmd.get_exe_bytes()
  File "../Python-3.1b1/Lib/distutils/command/bdist_wininst.py", line 
343, in get_exe_bytes
    return open(filename, "rb").read()
IOError: [Errno 21] Is a directory: '../Python-
3.1b1/Lib/distutils/command/wininst-6.0.exe'
....

% ./python.exe Lib/test/test_distutils.py
test_formats (distutils.tests.test_bdist.BuildTestCase) ... ok
test_simple_built (distutils.tests.test_bdist_dumb.BuildDumbTestCase) 
... ok
test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase) 
... ok
test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase) ... ok
test_get_exe_bytes 
(distutils.tests.test_bdist_wininst.BuildWinInstTestCase) ... ERROR
... <all other tests are ... ok>

======================================================================
ERROR: test_get_exe_bytes 
(distutils.tests.test_bdist_wininst.BuildWinInstTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../Python-3.1b1/Lib/distutils/tests/test_bdist_wininst.py", line 
23, in test_get_exe_bytes
    exe_file = cmd.get_exe_bytes()
  File "../Python-3.1b1/Lib/distutils/command/bdist_wininst.py", line 
343, in get_exe_bytes
    return open(filename, "rb").read()
IOError: [Errno 21] Is a directory: '../Python-
3.1b1/Lib/distutils/command/wininst-6.0.exe'

----------------------------------------------------------------------
Ran 97 tests in 0.948s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_distutils.py", line 17, in <module>
    test_main()
  File "Lib/test/test_distutils.py", line 13, in test_main
    test.support.run_unittest(distutils.tests.test_suite())
  File "../Python-3.1b1/Lib/test/support.py", line 878, in run_unittest
    _run_suite(suite)
  File "../Python-3.1b1/Lib/test/support.py", line 861, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "../Python-3.1b1/Lib/distutils/tests/test_bdist_wininst.py", line 
23, in test_get_exe_bytes
    exe_file = cmd.get_exe_bytes()
  File "../Python-3.1b1/Lib/distutils/command/bdist_wininst.py", line 
343, in get_exe_bytes
    return open(filename, "rb").read()
IOError: [Errno 21] Is a directory: '../Python-
3.1b1/Lib/distutils/command/wininst-6.0.exe'

% ./python.exe
Python 3.1b1 (r31b1:72412, May  7 2009, 09:16:22) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
components: Tests
messages: 87378
nosy: MrJean1
severity: normal
status: open
title: test_distutils fails for Python 3.1b1 on MacOS X
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu May  7 20:00:41 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 07 May 2009 18:00:41 +0000
Subject: [New-bugs-announce] [issue5957] Possible mistake regarding
	writeback in documentation of	shelve.open()
In-Reply-To: <1241719241.22.0.336086356581.issue5957@psf.upfronthosting.co.za>
Message-ID: <1241719241.22.0.336086356581.issue5957@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of shelve.open() states (paragraph 3) that "By
default, mutations to persistent-dictionary mutable entries are not
automatically written back." It then goes on to describe what happens if
the writeback parameter is True, which involves caching the entire
dictionary of objects in memory and writing the whole thing back on close.

But what happens if writeback is False, the default? The statement that
the mutable entires are not automatically written back leaves open the
question of how to write them back. shelf.sync() is documented as being
used only when writeback is true. Also, for a user unfamiliar with the
nuances of persistence the sentence quoted above is somewhat mysterious
-- "persistent-dictionary mutable entries"? "written back"?

----------
assignee: georg.brandl
components: Documentation
messages: 87381
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Possible mistake regarding writeback in documentation of shelve.open()
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu May  7 20:01:45 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 07 May 2009 18:01:45 +0000
Subject: [New-bugs-announce] [issue5958] Typo in documentation of shelve.sync
In-Reply-To: <1241719305.68.0.372814278118.issue5958@psf.upfronthosting.co.za>
Message-ID: <1241719305.68.0.372814278118.issue5958@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the documentation of shelve.sync, 'shelf' is mispelled 'Shelf' --
both the word and case are wrong.

----------
assignee: georg.brandl
components: Documentation
messages: 87382
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Typo in documentation of shelve.sync
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu May  7 20:24:54 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 07 May 2009 18:24:54 +0000
Subject: [New-bugs-announce] [issue5959] PyCode_NewEmpty
In-Reply-To: <1241720694.59.0.328707962514.issue5959@psf.upfronthosting.co.za>
Message-ID: <1241720694.59.0.328707962514.issue5959@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Most uses of PyCode_New found by
http://www.google.com/codesearch?q=PyCode_New are trying to build an
empty code object, usually to put it in a dummy frame object. This patch
adds a PyCode_NewEmpty wrapper which lets the user specify just the
filename, function name, and first line number, instead of also
requiring lots of code internals.

----------
components: Interpreter Core
files: PyCode_NewEmpty.patch
keywords: needs review, patch
messages: 87385
nosy: collinwinter, jyasskin
severity: normal
stage: patch review
status: open
title: PyCode_NewEmpty
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file13913/PyCode_NewEmpty.patch

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

From report at bugs.python.org  Thu May  7 20:32:48 2009
From: report at bugs.python.org (Eric Devolder)
Date: Thu, 07 May 2009 18:32:48 +0000
Subject: [New-bugs-announce] [issue5960] Windows Installer Error 1722 when
	opting for compilation	at install time - once again
In-Reply-To: <1241721168.05.0.823315409835.issue5960@psf.upfronthosting.co.za>
Message-ID: <1241721168.05.0.823315409835.issue5960@psf.upfronthosting.co.za>


New submission from Eric Devolder <eric.devolder at gmail.com>:

Hi,

Same problem as issue 4407, but on release 3.1b1 this time.

Guessing the same cure would apply...


for reference, here is the updated text, taken from event viewer:

Product: Python 3.1b1 -- Error 1722. There is a problem with this
Windows Installer package. A program run as part of the setup did not
finish as expected. Contact your support personnel or package vendor. 
Action CompilePyc, location: L:\Python31\python.exe, command: -Wi
"L:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "L:\Python31\Lib" 

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

----------
components: Installation
messages: 87387
nosy: keldonin
severity: normal
status: open
title: Windows Installer Error 1722 when opting for compilation at install time - once again
versions: Python 3.1

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

From report at bugs.python.org  Thu May  7 20:45:15 2009
From: report at bugs.python.org (Cary R.)
Date: Thu, 07 May 2009 18:45:15 +0000
Subject: [New-bugs-announce] [issue5961] Missing labelside option for Tix
	option menu (fix	included)
In-Reply-To: <1241721915.71.0.611768472614.issue5961@psf.upfronthosting.co.za>
Message-ID: <1241721915.71.0.611768472614.issue5961@psf.upfronthosting.co.za>


New submission from Cary R. <cygcary at yahoo.com>:

The Tix Optionmenu is documented to support a labelside option that is
used to specify where the label should be relative to the selection.

I have verified that adding 'labelside' to the static_options when
calling the base constructor (TixWidget.__init__) located in Tix.py line
1185 (for both 2.5.4 and 2.6.2) fixes the problem.

TixWidget.__init__(self, ... ,['labelside', 'options'], ... )

I am currently using 2.5.4, but a fix only for the 2.6 branch is
acceptable for all but my personal machine (which I can patch by hand).

I am not very familiar with how all this works, so if there is something
I can do from my code to add this option that would be nice to know.

----------
components: Tkinter
messages: 87388
nosy: caryr
severity: normal
status: open
title: Missing labelside option for Tix option menu (fix included)
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu May  7 20:53:15 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 07 May 2009 18:53:15 +0000
Subject: [New-bugs-announce] [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: <1241722395.44.0.880118568656.issue5962@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

I once was rather confused, because nothing in the sys and os modules
mentionned the behaviours that the exit() and _exit() functions were
supposed to have when called inside a non-main thread.
I've eventually found in multithreading-related docs that sys.exit()
made only the calling thread exit (without affecting the other threads
and the application), and I've eventually guessed that on the other
side, os._exit() always terminated the application wthout caring about
other threads or open files etc.
But I don't know if this will always be the case, or if using other
threading libraries than the standard one might change this semantics.

And concerning return code, I've found nothing indicating what happened
when different threads returned different codes. My experiments show
that only the main thread's return code is taken into account, but maybe
it's platform dependent (I'm on windows vista) ? 

So well, maybe we should add in the doc of sys and os some comments
about multithreading and returning codes, even if it is to say that
those are implementation details or platform dependant B-)

Regards, 
pascal

----------
assignee: georg.brandl
components: Documentation
messages: 87389
nosy: georg.brandl, pakal
severity: normal
status: open
title: Ambiguity about the semantics of sys.exit() and os._exit() in multithreaded program
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu May  7 21:31:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 May 2009 19:31:51 +0000
Subject: [New-bugs-announce] [issue5963] Doc error: integer precision in
	formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>


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

String Services / Format Specification Mini-Language (7.1.3.1 in 3.1)

"The precision is ignored for integer values."
in 3.0.1 and 3.1.b1 and, I presume in 2.6/7 doc

should be "A precision is not allowed for integer values."

(3.0.1)
>> format(10, '3x')
'  a'
>>> format(10, '.3x')
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    format(10, '.3x')
ValueError: Precision not allowed in integer format specifier

(I assume but cannot check that 2.6/7 behave the same.)

----------
assignee: georg.brandl
components: Documentation
messages: 87394
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Doc error: integer precision in formats
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri May  8 03:07:22 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 08 May 2009 01:07:22 +0000
Subject: [New-bugs-announce] [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

Running this code:

>>> import weakref
>>> class C: pass
...
>>> ws = weakref.WeakSet([C])
>>> if ws == 1:
...      print(1)
...

gives me the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    File "/home/bob/python/svn/py3k/Lib/_weakrefset.py", line 121, in __eq__
        return self.data == set(ref(item) for item in other)
        TypeError: 'int' object is not iterable

Looking at _weakrefset.py line 121 gives

  def __eq__(self, other):
      return self.data == set(ref(item) for item in other)

which treats any 'other' object as a set like object. Therefore
comparing WeakSet to a non-set-like object always fails.

Do I understand it correctly and if so, is this the intended behavior?

----------
components: Library (Lib)
messages: 87420
nosy: schuppenies
severity: normal
status: open
title: WeakSet cmp methods
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri May  8 03:31:32 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 May 2009 01:31:32 +0000
Subject: [New-bugs-announce] [issue5965] Format Specs: doc 's' and implicit
	conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>


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

String Services / Format Specification Mini-Language (7.1.3.1 in 3.1)
Building on #5963: document type 's' and implicit conversions.

Near the top, after
"A general convention is that an empty format string ("") produces the
same result as if you had called str() on the value."
add
"A non-empty format string typically modifies that result."

[This applies to all formats but particularly explains the point of 's',
present or implied.]

In the grammar box, add '" s " |' to the front of the list of types.

After "Finally, the type determines how the data should be presented." add
"Non-number values require 's' or no type.  Numbers are not allowed with
's'.

At the very end, add

"If an integer is used with a non-integer number presentation type
(those above other than 'n' or none) it is converted with float(). 
However, using a float or decimal with an integer-only presentation type
is not allowed."

----------
assignee: georg.brandl
components: Documentation
messages: 87421
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Format Specs: doc 's' and implicit conversions
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri May  8 09:32:30 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Fri, 08 May 2009 07:32:30 +0000
Subject: [New-bugs-announce] [issue5966] unnecessary hardlink
In-Reply-To: <1241767950.78.0.669934246491.issue5966@psf.upfronthosting.co.za>
Message-ID: <1241767950.78.0.669934246491.issue5966@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

After installing py3k:72466 I found that python3 is hardlink to 
python3.1:
$ ls -lai python*
34614 -rwxr-xr-x 2 root root 3625145 2009-05-08 11:10 python3
34614 -rwxr-xr-x 2 root root 3625145 2009-05-08 11:10 python3.1
38299 -rwxr-xr-x 1 root root    1406 2009-05-08 11:10 python3.1-config
34616 lrwxrwxrwx 1 root root      16 2009-05-08 11:10 python3-config -> 
python3.1-config

I'm expecting symlink python3 pointing to python3.1(as python is symlink 
to python2.5 in my system). It's much easy to manage symlinks than 
hardlinks.

----------
components: Installation
messages: 87428
nosy: exe
severity: normal
status: open
title: unnecessary hardlink
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri May  8 14:35:57 2009
From: report at bugs.python.org (Campbell Barton)
Date: Fri, 08 May 2009 12:35:57 +0000
Subject: [New-bugs-announce] [issue5967] PyList_GetSlice does not indicate
	negative ranges dont	work as in python.
In-Reply-To: <1241786157.93.0.55086599633.issue5967@psf.upfronthosting.co.za>
Message-ID: <1241786157.93.0.55086599633.issue5967@psf.upfronthosting.co.za>


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

simple patch, docs say that PyList_GetSlice() works like list[high:low],
but does not say that negative indices's dont work as with python slicing.

----------
assignee: georg.brandl
components: Documentation
files: slice.diff
keywords: patch
messages: 87438
nosy: georg.brandl, ideasman42
severity: normal
status: open
title: PyList_GetSlice does not indicate negative ranges dont work as in python.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13922/slice.diff

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

From report at bugs.python.org  Fri May  8 15:24:50 2009
From: report at bugs.python.org (Sven Rahmann)
Date: Fri, 08 May 2009 13:24:50 +0000
Subject: [New-bugs-announce] [issue5968] Generator expression bug?
In-Reply-To: <1241789090.54.0.0922796192042.issue5968@psf.upfronthosting.co.za>
Message-ID: <1241789090.54.0.0922796192042.issue5968@psf.upfronthosting.co.za>


New submission from Sven Rahmann <svenrahmann at googlemail.com>:

Lists from list comprehensions and generator objects from generator
expressions behave differently when we repeatedly want to iterate over them.

This may or may not be a bug, but it is certainly not clear from the
documentation (see documentation of "for" statement in all recent python
versions).

The reason seems to be that generator expressions, once exhausted, are
not reset by using them again in a for loop.
This is different for lists and range objects.

The attached example illustrates the phenomenon.
It is written for Python 3, but the same phenomenon occurs in the 2.x
series.

----------
files: generatorbug1.py
messages: 87440
nosy: svenrahmann
severity: normal
status: open
title: Generator expression bug?
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13923/generatorbug1.py

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

From report at bugs.python.org  Fri May  8 16:03:47 2009
From: report at bugs.python.org (Marc Schoenefeld)
Date: Fri, 08 May 2009 14:03:47 +0000
Subject: [New-bugs-announce] [issue5969] setup build with Platform SDK,
	finding vcvarsall.bat
In-Reply-To: <1241791427.1.0.931613951559.issue5969@psf.upfronthosting.co.za>
Message-ID: <1241791427.1.0.931613951559.issue5969@psf.upfronthosting.co.za>


New submission from Marc Schoenefeld <marc.schoenefeld at gmx.org>:

Hi, 

I have the M$ Platform SDK installed, which 
is a free (as don't pay) alternative to 
VisualStudio.   

in order to achieve a successful compile with 
setup.py build on the Platform SDK I 
had to add the following change in 
distutils/msvc9compiler.py: 

Best regards
Marc 

Patch draft:

def find_vcvarsall(version):
       
+   vcvarsall = os.path.join(productdir+"\\bin", "vcvars32.bat")
-   vcvarsall = os.path.join(productdir, "vcvarall.bat")

 
   if os.path.isfile(vcvarsall):

----------
assignee: tarek
components: Distutils
messages: 87442
nosy: MarcMarc, tarek
severity: normal
status: open
title: setup build with Platform SDK, finding vcvarsall.bat
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri May  8 19:44:01 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 08 May 2009 17:44:01 +0000
Subject: [New-bugs-announce] [issue5970] sys.exc_info leaks into a generator
In-Reply-To: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>
Message-ID: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

There's an obscure bug in sys.exc_info after a yield statement.

  def test():
      def raising_generator():
          try:
              raise IndexError("inner exception")
          except IndexError:
              yield 3
              # Here, sys.exc_info() ought to refer to the inner
              # exception, but instead it refers to the outer one.
      try:
          raise ValueError("outer exception")
      except ValueError:
          for i in raising_generator(): pass

sys.exc_info gets reset even if there's no outer exception.

The attached (failing) patch highlights this problem, and tests other
sys.exc_info behavior around function calls.

----------
components: Interpreter Core
files: exc_info.patch
keywords: patch
messages: 87452
nosy: collinwinter, jyasskin
priority: low
severity: normal
stage: needs patch
status: open
title: sys.exc_info leaks into a generator
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13927/exc_info.patch

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

From report at bugs.python.org  Fri May  8 22:55:54 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Fri, 08 May 2009 20:55:54 +0000
Subject: [New-bugs-announce] [issue5971] logging.Handler.handlerError() may
	raise IOError in	traceback.print_exception()
In-Reply-To: <1241816154.36.0.958687458985.issue5971@psf.upfronthosting.co.za>
Message-ID: <1241816154.36.0.958687458985.issue5971@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

When using the logging package, if a StreamHandler is configured with
stderr and stderr is redirected to a pipe which no longer has readers,
then StreamHandler.emit() will result in an IOError for "Broken pipe".
The exception will be handled in logging.Handler.handleError(), which by
default will call traceback.print_exception() with file=sys.stderr. This
will cause in a second IOError exception which will not be caught within
the logging code. Unless the user placed their log calls such as
logging.info() in a try/except block (unlikely), the end result is
termination of the process.

While the logging code itself is certainly not the cause of the
underlying problem, it does seem that the intent of the default
handleError() was to eat exceptions, and possibly print them, without
disturbing the application code. As the docstring correctly points out,
the application can probably survive without the logging.

To work around this issue without writing a custom handler,
raiseExceptions can be set to false. But then the user would miss log
trace when other types of errors not affecting stderr occurred. That is,
I think handleError() does the right thing in trying to print the error,
but suggest that if the print results in an IOError (or certain types of
IOError), then it should be ignored, or optionally ignorable.

----------
components: Library (Lib)
messages: 87469
nosy: ryles
severity: normal
status: open
title: logging.Handler.handlerError() may raise IOError in traceback.print_exception()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri May  8 23:20:14 2009
From: report at bugs.python.org (Denise Mauldin)
Date: Fri, 08 May 2009 21:20:14 +0000
Subject: [New-bugs-announce] [issue5972] Failing test_signal.py on Redhat
	4.1.2-44
In-Reply-To: <1241817614.78.0.115572621899.issue5972@psf.upfronthosting.co.za>
Message-ID: <1241817614.78.0.115572621899.issue5972@psf.upfronthosting.co.za>


New submission from Denise Mauldin <denise_rpga at yahoo.com>:

Building python 2.6.2 on red hat linux 4.1.2-44 fails test_signal.py

cat /proc/version
Linux version 2.6.18-128.1.6.el5 (mockbuild at builder10.centos.org) (gcc
version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Apr 1 09:10:25 EDT
2009

Failed when running make test, failed when running test for the first
time, completed after running test again, then failed when running for a
3rd time.  

./python ./Lib/test/test_signal.py
test_getsignal (__main__.BasicSignalTests) ... ok
test_out_of_range_signal_number_raises_error (__main__.BasicSignalTests)
... ok
test_setting_signal_handler_to_none_raises_error
(__main__.BasicSignalTests) ... ok
test_main (__main__.InterProcessSignalTests) ... test runner's pid is 16310
handlerA invoked from signal 1 at:
  File "/local/python/src/Python-2.6.2/Lib/subprocess.py", line 1123, in
wait
    pid, sts = os.waitpid(self.pid, 0)

handlerB invoked from signal 10 at:
  File "/local/python/src/Python-2.6.2/Lib/subprocess.py", line 1123, in
wait
    pid, sts = os.waitpid(self.pid, 0)

HandlerBCalled exception caught
KeyboardInterrupt (the alarm() went off)
ok
test_wakeup_fd_during (__main__.WakeupSignalTests) ... ok
test_wakeup_fd_early (__main__.WakeupSignalTests) ... ok
test_siginterrupt_off (__main__.SiginterruptTest) ... ok
test_siginterrupt_on (__main__.SiginterruptTest) ... ok
test_without_siginterrupt (__main__.SiginterruptTest) ... ok
test_itimer_exc (__main__.ItimerTest) ... ok
test_itimer_prof (__main__.ItimerTest) ... ('SIGPROF handler invoked',
(27, <frame object at 0x1edab860>))
ok
test_itimer_real (__main__.ItimerTest) ...
call pause()...
('SIGALRM handler invoked', (14, <frame object at 0x1edabf30>))
ok
test_itimer_virtual (__main__.ItimerTest) ... FAIL

======================================================================
FAIL: test_itimer_virtual (__main__.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 368, in test_itimer_virtual
    self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0))
AssertionError: (0.29595500000000002, 0.20096900000000001) != (0.0, 0.0)


----------------------------------------------------------------------
Ran 13 tests in 66.251s

FAILED (failures=1)
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 392, in <module>
    test_main()
  File "./Lib/test/test_signal.py", line 388, in test_main
    WakeupSignalTests, SiginterruptTest, ItimerTest)
  File "/local/python/src/Python-2.6.2/Lib/test/test_support.py", line
722, in run_unittest
    _run_suite(suite)
  File "/local/python/src/Python-2.6.2/Lib/test/test_support.py", line
705, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 368, in test_itimer_virtual
    self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0))
AssertionError: (0.29595500000000002, 0.20096900000000001) != (0.0, 0.0)

----------
components: Installation
messages: 87472
nosy: dmauldin
severity: normal
status: open
title: Failing test_signal.py on Redhat 4.1.2-44
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri May  8 23:26:19 2009
From: report at bugs.python.org (Sven Rahmann)
Date: Fri, 08 May 2009 21:26:19 +0000
Subject: [New-bugs-announce] [issue5973] re-usable generators / generator
	expressions should	return iterables
In-Reply-To: <1241817979.06.0.302346555746.issue5973@psf.upfronthosting.co.za>
Message-ID: <1241817979.06.0.302346555746.issue5973@psf.upfronthosting.co.za>


New submission from Sven Rahmann <svenrahmann at googlemail.com>:

The syntax of generator expressions suggests that they can be used
similarly to lists (at least when iterated over).
However, as was pointed out to me, the resulting generators are
iterators and can be used only once.
This is inconvenient in situations where some function expects an
iterable argument but needs to iterate over it more than once.

Consider the following function (see also attached file
reusable_generators.py for a complete example)

def secondmax(iterable):
    """return the second largest value in iterable"""
    m = max(iterable)
    return max(i for i in iterable if i<m)

It works fine when passed a list or other iterable container, but
consider the following situation. We have a huge matrix A (list of
lists) and want to pass a column to the function.

Using a list works fine, but requires copying the column's values and
needs additional memory:

col2_list = [a[2] for a in A]  # new list created from column 2

There is no reason why we shouldn't be able to create an iterable object
that returns, one by one, the values from the colums:

col2_gen  = (a[2] for a in A) 

The problem is that secondmax(col2_gen) does not work; try the attached
file: col2_gen can be iterated over only once.

I can imagine many situations where I need or want to iterate over such
a "view" object several times; I don't see a reason why it shouldn't be
possible or why it would be unwanted.

We can do the following, but it is not elegant: Wrap the generator
expression into a closure and a class.

class ReusableGenerator():
    def __init__(self,g): self.g = g
    def __iter__(self):   return self.g()

col2_re = ReusableGenerator(lambda: (a[2] for a in A)) # I want this!

This works, but it is not a generator object (e.g., it doesn't have a
next method). We also need the lambda detour for this to work.

Note that in some situations, the "problem" I describe does not occur or
can be easily circumvented. For example instead of writing

col2 = (a[2] for a in A) 
for x in col2: foo(x)
for x in col2: foo(x) # doesn't work

we could just repeat the generator expression (and create a new iterator
whenever we need it):

for x in (a[2] for a in A): foo(x)
for x in (a[2] for a in A): foo(x) # works fine

But exactly this is impossible if I want to pass the generator
expression or generator function to another function (such as secondmax()). 

I believe this contradicts Python philosophy that functions can be
passed around just like other objects.


My proposal is probably unrealistic, but I would like to see generator
functions and generator expressions change in a way that they return not
iterators, but iterables, so the problem described here does not occur,
and wrapper classes are unnecessary.

In Java that distinction is very clear, in Python less so I think (which
is good because iterators are a pain to use in Java).


Admittedly, I have no idea why generator functions and expressions are
implemented as they are; there are probably lots of good reasons, and it
may not be possible to change this any time soon or at all.
However, I think the change would make Python a more consistent language.

----------
files: reusable_generators.py
messages: 87473
nosy: svenrahmann
severity: normal
status: open
title: re-usable generators / generator expressions should return iterables
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13936/reusable_generators.py

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

From report at bugs.python.org  Sat May  9 00:11:43 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 08 May 2009 22:11:43 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue5974=5D_unicode_decode_erro?=
 =?utf-8?q?r_due_to_improperly_entered_text_=22Martin_v=2E_L=C3=B6wis=22?=
In-Reply-To: <1241820703.89.0.000181107829527.issue5974@psf.upfronthosting.co.za>
Message-ID: <1241820703.89.0.000181107829527.issue5974@psf.upfronthosting.co.za>


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

$ python3.1 -Wi -tt -O
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/compileall.py
-x badsyntax -x site-packages -x test
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/command/
Listing
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/command/
...
Compiling
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/command/bdist_msi.py
...
*** UnicodeDecodeError: 'utf8' codec can't decode bytes in position
62-65: invalid data


...

$ grep -R Martin
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1//Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/command/bdist_msi.py:#
Copyright (C) 2005, 2006 Martin v. L####
....
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/CREDITS.txt:Jim
Jewett, Martin v. L####, Jason Orendorff, Guilherme Polo, Josh Robb,

..

This is causing the ActivePython postinstall script to fail.

As a suggestion only, it may be a good idea to have a separate test case
that to look for unicode decode errors in modules.

----------
assignee: tarek
components: Distutils
messages: 87476
nosy: srid, tarek, trentm
severity: normal
status: open
title: unicode decode error due to improperly entered text "Martin v. L?wis"
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Sat May  9 00:31:10 2009
From: report at bugs.python.org (Jay Talbot)
Date: Fri, 08 May 2009 22:31:10 +0000
Subject: [New-bugs-announce] [issue5975] csv unix file format ('\n' line
	terminator)
In-Reply-To: <1241821870.32.0.544896440632.issue5975@psf.upfronthosting.co.za>
Message-ID: <1241821870.32.0.544896440632.issue5975@psf.upfronthosting.co.za>


New submission from Jay Talbot <jay.talbot at gmail.com>:

I was having issues importing a csv file generated by the csv.write
class with the following:

load data infile 'file.csv' replace into table en fields terminated by
',' enclosed by '"' lines terminated by '\r\n';

To help prevent this from happening again, I would like to see the
following added to the csv.py library:

class unix_dialect(Dialect):
    """Describe the usual properties of unix-generated CSV files."""
    delimiter = ','
    quotechar = '"'
    doublequote = True
    skipinitialspace = False
    lineterminator = '\n'
    quoting = QUOTE_ALL
register_dialect("unix_dialect", unix_dialect)

The above code is the excel class dialect with '\n' line termination and
quoting of all fields. This allows for easy csv file import into mysql
databases.

----------
components: Library (Lib)
messages: 87479
nosy: jtalbot
severity: normal
status: open
title: csv unix file format ('\n' line terminator)
type: feature request
versions: Python 2.5, Python 2.6, Python 3.0

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 11:48:10 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 09 May 2009 09:48:10 +0000
Subject: [New-bugs-announce] [issue5976] test_os fails if run after
	test_distutils
In-Reply-To: <1241862490.7.0.561537062217.issue5976@psf.upfronthosting.co.za>
Message-ID: <1241862490.7.0.561537062217.issue5976@psf.upfronthosting.co.za>


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

./python Lib/test/regrtest.py -v test_distutils test_os

----------
assignee: tarek
components: Distutils
messages: 87487
nosy: tarek
priority: critical
severity: normal
status: open
title: test_os fails if run after test_distutils
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat May  9 15:29:50 2009
From: report at bugs.python.org (kxroberto)
Date: Sat, 09 May 2009 13:29:50 +0000
Subject: [New-bugs-announce] [issue5977] distutils build_ext.get_outputs
	returns wrong result	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>


New submission from kxroberto <kxroberto at users.sourceforge.net>:

with --inplace etc. build_ext.get_outputs returns wrong extension paths;
tries to computes them out of the air *again* and ..

Tools which need to further know the produced module file, e.g.
pyximport (Cython) do crash then ...

patch see attachment: stores and uses the real path in use.
writes a new attribute ext_filename to Extension object - should it be
underscored _ext_filename or ... ?

----------
assignee: tarek
components: Distutils
files: ext_filename.patch
keywords: patch
messages: 87494
nosy: kxroberto, tarek
severity: normal
status: open
title: distutils build_ext.get_outputs returns wrong result (patch)
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file13941/ext_filename.patch

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

From report at bugs.python.org  Sat May  9 20:57:28 2009
From: report at bugs.python.org (Akkana Peck)
Date: Sat, 09 May 2009 18:57:28 +0000
Subject: [New-bugs-announce] [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: <1241895448.39.0.497331485225.issue5978@psf.upfronthosting.co.za>


New submission from Akkana Peck <akkzilla at shallowsky.com>:

I was following the steps at http://docs.python.org/library/profile.html
to try to profile a pygtk program, but it wasn't working -- I was
getting no output at all from either cProfile or profile.

The problem turned out to be that I was exiting by calling sys.exit(0),
because that's what most pygtk programs I'd seen were doing. Changing
that to gtk.main_quit() made profiling work (but it took a long time to
track that down).

Apparently the same thing happens in pyqt if you call sys.exit(0).

----------
components: Demos and Tools
files: pywin
messages: 87504
nosy: akkana
severity: normal
status: open
title: cProfile and profile don't work with pygtk/pyqt and sys.exit(0)
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file13943/pywin

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

From report at bugs.python.org  Sat May  9 21:14:10 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sat, 09 May 2009 19:14:10 +0000
Subject: [New-bugs-announce] [issue5979] strptime() gives inconsistent
	exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

e.g.

>>> from datetime import datetime
>>>
>>> datetime.strptime("19951001", "%Y%m%d")
datetime.datetime(1995, 10, 1, 0, 0)
>>>
>>> datetime.strptime("19951000", "%Y%m%d") # day = 0, month < 11
 ...
ValueError: time data '19951000' does not match format '%Y%m%d'
>>>
>>> datetime.strptime("19951100", "%Y%m%d") # day = 0, month >= 11
 ...
ValueError: unconverted data remains: 0
>>>

The exception messages are not really a serious issue, but note that the
latter one can be confusing for users.

However, there seems to be some underlying issues with the choice to
recognize single digit months with double digit days, which can make
date strings ambiguous:

Consider "19951100" from above with the last '0' removed.

>>> datetime.strptime("1995110", "%Y%m%d")
datetime.datetime(1995, 1, 10, 0, 0)
>>>

In this case, strptime has treated the middle '1' as the month,
resulting in 1995-01-10. This hints at why the second exception from
above gives a strange message: with the extra '0' the day portion of
"19951100" (00) is invalid, and strptime falls back on parsing the first
7 characters as above, and then failing due to the remaining '0'.

This seems a little dangerous. For instance:
timestamp = "19951101-23:20:18"
datestamp=timestamp[:7] # Oops, needed to use :8 to get up to index 7.
reallyImportantButWrongDate = datetime.strptime(datestamp, "%Y%m%d")

Note that in this case strptime() from glibc would instead result in an
error, which IMHO is the right thing to do.

I do realize, though, that changing the behavior of strptime() could
devastate some existing code.

----------
components: Library (Lib)
messages: 87505
nosy: ryles
severity: normal
status: open
title: strptime() gives inconsistent exceptions
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat May  9 21:24:25 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 09 May 2009 19:24:25 +0000
Subject: [New-bugs-announce] [issue5980] Add bug tracker tasks to PEP 101
In-Reply-To: <1241897065.28.0.181996092756.issue5980@psf.upfronthosting.co.za>
Message-ID: <1241897065.28.0.181996092756.issue5980@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This patch would add the following bug tracker tasks to PEP 101 (Doing
Python Releases 101):
 - Add version X.Y+1 as when version X.Y enters alpha.

 - Change non-doc RFEs to version X.Y+1 when version X.Y enters beta.

 - Update 'behavior' issues from versions that your release make
   unsupported to the next supported version.

 - Review open issues, as this might find lurking showstopper bugs,
   besides reminding people to fix the easy ones they forgot about.

These are the changes mentioned in
http://psf.upfronthosting.co.za/roundup/meta/issue283

However, I'm tempted to update PEP 3 (Guidelines for Handling Bug
Reports) instead, adding these (and the blocker <-> deferred flips) as
tracker janitors' tasks.

What do you think?

----------
assignee: georg.brandl
components: Documentation
files: bugtracker.diff
keywords: patch
messages: 87508
nosy: ajaksu2, georg.brandl, loewis
priority: low
severity: normal
status: open
title: Add bug tracker tasks to PEP 101
type: feature request
Added file: http://bugs.python.org/file13944/bugtracker.diff

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

From report at bugs.python.org  Sat May  9 21:50:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 May 2009 19:50:17 +0000
Subject: [New-bugs-announce] [issue5981] float.fromhex bugs
In-Reply-To: <1241898617.16.0.557804357136.issue5981@psf.upfronthosting.co.za>
Message-ID: <1241898617.16.0.557804357136.issue5981@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Two problems with float.fromhex:

(1) it incorrectly rejects trailing whitespace on infs and nans:

>>> float.fromhex('a.0 ')
10.0
>>> float.fromhex('nan ')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid hexadecimal floating-point string

(2) The implementation uses PyOS_strnicmp for detecting nans and infs,
which is locale-aware.  A locale-unaware case-insensitive comparison 
should be used instead.  I don't know of any locale where this actually 
makes a difference, but I think it should be fixed anyway.

----------
assignee: marketdickinson
components: Interpreter Core
messages: 87509
nosy: marketdickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: float.fromhex bugs
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat May  9 23:05:03 2009
From: report at bugs.python.org (George Sakkis)
Date: Sat, 09 May 2009 21:05:03 +0000
Subject: [New-bugs-announce] [issue5982] classmethod,
	staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>


New submission from George Sakkis <george.sakkis at gmail.com>:

It would be nice if classmethod/staticmethod exposed the wrapped
function as a read-only attribute/property. Currently the function can
be retrieved indirectly but it's obscure (and perhaps not always
correct, I'm not sure):

In [147]: def f():pass
   .....: 

In [148]: c = classmethod(f)

In [149]: s = staticmethod(f)

In [150]: c.__get__(1).im_func is f
Out[150]: True

In [151]: s.__get__(1) is f
Out[151]: True

----------
messages: 87511
nosy: gsakkis
severity: normal
status: open
title: classmethod, staticmethod: expose wrapped function
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sat May  9 23:28:27 2009
From: report at bugs.python.org (schmirrwurst)
Date: Sat, 09 May 2009 21:28:27 +0000
Subject: [New-bugs-announce] [issue5983] boolean.so no more in _xmlplus/utils
In-Reply-To: <1241904507.75.0.715098012356.issue5983@psf.upfronthosting.co.za>
Message-ID: <1241904507.75.0.715098012356.issue5983@psf.upfronthosting.co.za>


New submission from schmirrwurst <schmirrwurst at free.fr>:

We are a few experiencing a failure with openerp on ubuntu.
We are missing the file  boolean.so from _xmlplus/utils/ in python 2.5 and 2.6

instead we found it in /usr/lib/python2.x/dist-packages/oldxml/_xmlplus/utils/

is it normal ?

bug report on lp :
https://bugs.launchpad.net/ubuntu/+source/python-xml/+bug/343242/
https://bugs.launchpad.net/ubuntu/+source/openerp-server/+bug/337759

----------
messages: 87512
nosy: schmirrwurst
severity: normal
status: open
title: boolean.so no more in _xmlplus/utils
type: resource usage
versions: Python 2.5, Python 2.6

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 10 11:39:08 2009
From: =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sun, 10 May 2009 09:39:08 +0000
Subject: [New-bugs-announce] [issue5984]
	distutils.command.build_ext.check_extensions_list broken	checkings
In-Reply-To: <1241948348.34.0.593994545103.issue5984@psf.upfronthosting.co.za>
Message-ID: <1241948348.34.0.593994545103.issue5984@psf.upfronthosting.co.za>


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

distutils.command.build_ext.check_extensions_list is not really working
for old style extensions.

Will fix it and put a pending deprecation warning for 2.7 and 3.1
(then remove it under 3.2)

----------
assignee: tarek
components: Distutils
messages: 87517
nosy: tarek
severity: normal
status: open
title: distutils.command.build_ext.check_extensions_list broken checkings
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun May 10 12:02:48 2009
From: report at bugs.python.org (Erik Sandberg)
Date: Sun, 10 May 2009 10:02:48 +0000
Subject: [New-bugs-announce] [issue5985] Implement os.path.samefile and
	os.path.sameopenfile on	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>


New submission from Erik Sandberg <sandberg at virtutech.com>:

It would be nice if samefile / sameopenfile was present on Windows.
Right now I usually work around this by keeping a platform-specific hack
for Windows that approximates samefile by comparing normalized paths;
this is ugly and doesn't handle junctions correctly.

In one of my projects I have written a C implementation of samefile,
which I manually monkey-patched os.path with. It would probably be
rather easy to adapt it to become a native part of ntpath.

My code relies on GetFileInformationByHandle, which is only available in
Windows 2000 professional and newer
(http://msdn.microsoft.com/en-us/library/aa364952(VS.85).aspx); if I
understood it correctly this should not be a problem as Python 2.6 and
newer doesn't support older versions of Windows.

Unfortunately I don't use Windows myself, but I have rdesktop access to
an XP machine with cygwin and Visual Studio 2005 installed (which seems
insufficient to build python 2.6, at least), so it will be difficult for
me to test my code. But I'll post some code soon.

----------
messages: 87518
nosy: sandberg
severity: normal
status: open
title: Implement os.path.samefile and os.path.sameopenfile on Windows
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun May 10 19:29:36 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 May 2009 17:29:36 +0000
Subject: [New-bugs-announce] [issue5986] Avoid reversed() in Random.shuffle()
In-Reply-To: <1241976576.36.0.361405566006.issue5986@psf.upfronthosting.co.za>
Message-ID: <1241976576.36.0.361405566006.issue5986@psf.upfronthosting.co.za>


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

reversed(xrange(1, len(x))) is inefficient, xrange(len(x) - 1, 0, -1) 
gives exactly the same sequence but avoid reversed(). See attached 
patch. Don't expect amazing speedup.

----------
components: Library (Lib)
files: shuffle.patch
keywords: patch
messages: 87531
nosy: haypo
severity: normal
status: open
title: Avoid reversed() in Random.shuffle()
Added file: http://bugs.python.org/file13947/shuffle.patch

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

From report at bugs.python.org  Sun May 10 20:53:41 2009
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 10 May 2009 18:53:41 +0000
Subject: [New-bugs-announce] [issue5987] Broken link to "Curses Programming
	with Python"
In-Reply-To: <1241981621.95.0.54234756767.issue5987@psf.upfronthosting.co.za>
Message-ID: <1241981621.95.0.54234756767.issue5987@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

http://www.python.org/doc/2.5.2/lib/module-curses.html links to
http://docs.python.org/dev/howto/index.htmlcurses/curses.html as "Curses
Programming with Python" but it's 404 Not Found.

It may be that this link is broken in other Python versions, 2.5.2 is
just the one I refer to for Ubuntu 8.04.

----------
assignee: georg.brandl
components: Documentation
messages: 87535
nosy: georg.brandl, ralph.corderoy
severity: normal
status: open
title: Broken link to "Curses Programming with Python"
versions: Python 2.5

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

From report at bugs.python.org  Sun May 10 20:55:43 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 10 May 2009 18:55:43 +0000
Subject: [New-bugs-announce] [issue5988] Delete PyOS_ascii_formatd,
	PyOS_ascii_strtod, and PyOS_ascii_atof
In-Reply-To: <1241981743.74.0.769562552261.issue5988@psf.upfronthosting.co.za>
Message-ID: <1241981743.74.0.769562552261.issue5988@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

These 3 functions were deprecated in 2.7 and 3.1, and need to be removed
in 2.8 and 3.2.

This is currently assigned to version 3.2 only because the bug tracker
can't assign issues to 2.8.

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 87536
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
status: open
title: Delete PyOS_ascii_formatd, PyOS_ascii_strtod, and PyOS_ascii_atof
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun May 10 22:04:20 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 May 2009 20:04:20 +0000
Subject: [New-bugs-announce] [issue5989]
	unittest.TestLoader.loadTestsFromNames should accept	module /
	class name
In-Reply-To: <1241985860.54.0.789290376595.issue5989@psf.upfronthosting.co.za>
Message-ID: <1241985860.54.0.789290376595.issue5989@psf.upfronthosting.co.za>


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

It would be really nice if unittest.TestLoader.loadTestsFromNames
accepted module and class names.

My main motivation for that is so that I can do:

    python -m unittest module_name

There is no backwards compatibility issue as currently this doesn't work...

Really easy to add.

----------
assignee: michael.foord
components: Library (Lib)
messages: 87540
nosy: michael.foord
severity: normal
status: open
title: unittest.TestLoader.loadTestsFromNames should accept module / class name
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun May 10 22:44:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:44:54 +0000
Subject: [New-bugs-announce] [issue5990] Memory leak in os.rename() and
	other functions
In-Reply-To: <1241988294.2.0.773567754843.issue5990@psf.upfronthosting.co.za>
Message-ID: <1241988294.2.0.773567754843.issue5990@psf.upfronthosting.co.za>


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

A small memory leak appeared in test_os with the PEP 383 checkins. The
leak occurs in test_rename and is due to posix_2str. Here is a patch.

----------
components: Library (Lib)
files: os_leak.patch
keywords: patch
messages: 87543
nosy: loewis, pitrou
priority: high
severity: normal
stage: patch review
status: open
title: Memory leak in os.rename() and other functions
type: resource usage
versions: Python 3.1
Added file: http://bugs.python.org/file13951/os_leak.patch

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

From report at bugs.python.org  Mon May 11 01:53:23 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sun, 10 May 2009 23:53:23 +0000
Subject: [New-bugs-announce] [issue5991] Add non-command help topics to help
	completion of cmd.Cmd
In-Reply-To: <1241999603.41.0.146280599558.issue5991@psf.upfronthosting.co.za>
Message-ID: <1241999603.41.0.146280599558.issue5991@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

The cmd.Cmd module has a default complete_help() method which will
complete all existing commands (methods starting with "do_").  It would
be useful to complete all exising help topics too by default, i.e. all
methods starting with "help_".

The attached patch does this.

----------
components: Library (Lib)
files: cmd.diff
keywords: patch
messages: 87557
nosy: flub
severity: normal
status: open
title: Add non-command help topics to help completion of cmd.Cmd
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file13954/cmd.diff

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

From report at bugs.python.org  Mon May 11 01:56:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 23:56:50 +0000
Subject: [New-bugs-announce] [issue5992] spurious space after opening
	parenthesis when	auto-completing
In-Reply-To: <1241999810.49.0.16520968517.issue5992@psf.upfronthosting.co.za>
Message-ID: <1241999810.49.0.16520968517.issue5992@psf.upfronthosting.co.za>


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

Recent trunk/py3k revisions add a spurious space character after the
opening parenthesis when doing completion at the interpreter prompt. For
example if you type "he" and then press the Tab key, it will display
"help( " instead of "help(".

----------
messages: 87558
nosy: pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: spurious space after opening parenthesis when auto-completing
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon May 11 05:57:58 2009
From: report at bugs.python.org (dontbugme)
Date: Mon, 11 May 2009 03:57:58 +0000
Subject: [New-bugs-announce] [issue5993] python produces zombie in
	webbrowser.open
In-Reply-To: <1242014278.58.0.774883846907.issue5993@psf.upfronthosting.co.za>
Message-ID: <1242014278.58.0.774883846907.issue5993@psf.upfronthosting.co.za>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

the webbrowser library produces a zombie process when opening urls.

please see http://dev.deluge-torrent.org/ticket/928
and the original bug report (by me) on ubuntu's launchpad (https://
bugs.launchpad.net/bugs/313149) for details.
could not find any references in your tracker, but i did not test it in 
newer versions than the one supplied in ubuntu atm (2.6.2), so please 
forgive me, if it is already fixed :)

----------
components: Library (Lib)
messages: 87561
nosy: dontbugme
severity: normal
status: open
title: python produces zombie in webbrowser.open
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Mon May 11 12:41:34 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 11 May 2009 10:41:34 +0000
Subject: [New-bugs-announce] [issue5994] help(marshal) just gives an outline;
	no help text provided.
In-Reply-To: <1242038494.64.0.807465783139.issue5994@psf.upfronthosting.co.za>
Message-ID: <1242038494.64.0.807465783139.issue5994@psf.upfronthosting.co.za>


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

Help on built-in module marshal:

NAME
    marshal

FILE
    (built-in)

MODULE DOCS
    http://docs.python.org/library/marshal

FUNCTIONS
    dump(...)
    
    dumps(...)
    
    load(...)
    
    loads(...)

DATA
    version = 2

----------
assignee: georg.brandl
components: Documentation
messages: 87570
nosy: georg.brandl, orsenthil
priority: normal
severity: normal
status: open
title: help(marshal) just gives an outline; no help text provided.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon May 11 12:59:48 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 May 2009 10:59:48 +0000
Subject: [New-bugs-announce] [issue5995] unittest command line behaviour
In-Reply-To: <1242039588.66.0.255791822903.issue5995@psf.upfronthosting.co.za>
Message-ID: <1242039588.66.0.255791822903.issue5995@psf.upfronthosting.co.za>


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

This patch adds a verbosity keyword argument to unittest.main - so you
can do:

    if __name__ == '__main__':
       unittest.main(verbosity=2)

It also has a minor fix allowing you to specify test modules / classes
from the command line. This enables unittest to be used like this:

    python -m unittest test_module
    python -m unittest test_module.TestClass

Which is quite funky.

----------
assignee: michael.foord
components: Library (Lib)
files: unittest.patch
keywords: easy, needs review, patch, patch
messages: 87571
nosy: michael.foord
severity: normal
stage: patch review
status: open
title: unittest command line behaviour
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13956/unittest.patch

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

From report at bugs.python.org  Mon May 11 16:06:03 2009
From: report at bugs.python.org (johannes raggam)
Date: Mon, 11 May 2009 14:06:03 +0000
Subject: [New-bugs-announce] [issue5996] abstract class instantiable when
	subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>


New submission from johannes raggam <raggam-nl at adm.at>:

when declaring a abstract base class with an abstract property or method
and subclassing from dict, the class is instantiable (instanceable?).

>>> import abc
>>> class A(object):
...     __metaclass__ = abc.ABCMeta
...     @abc.abstractproperty
...     def abstract(self): return True
... 
>>> a = A()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class A with abstract methods abstract
>>> 
>>> class A2(dict):
...     __metaclass__ = abc.ABCMeta
...     @abc.abstractproperty
...     def abstract(self): return True
... 
>>> a2 = A2()
>>> 


although, when using the dict definition from __builtin__.pi directly,
the abc behaves like expected. but this may be a bug in the
c-implementation from dict.

platform:
Python 2.6.2 (r262:71600, Apr 25 2009, 21:56:41) 
[GCC 4.3.2] on linux2

----------
components: Library (Lib)
messages: 87574
nosy: thet
severity: normal
status: open
title: abstract class instantiable when subclassing dict
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May 11 19:58:27 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 11 May 2009 17:58:27 +0000
Subject: [New-bugs-announce] [issue5997] strftime is broken
In-Reply-To: <1242064707.21.0.409196088491.issue5997@psf.upfronthosting.co.za>
Message-ID: <1242064707.21.0.409196088491.issue5997@psf.upfronthosting.co.za>


New submission from Jonathan <jonathan.cervidae at gmail.com>:

[jon at jaydee Development]$ cat is-strftime-broken.py
#!/usr/bin/env python
import subprocess
import time
date_process = subprocess.Popen(
    ("date", "+%x"), stdout=subprocess.PIPE)
from_date_command = date_process.communicate()[0].rstrip()
from_strftime = time.strftime("%x")
print "Date command returns %s, strftime returns %s" % (
    from_date_command, from_strftime )
[jon at jaydee Development]$ python ./is-strftime-broken.py
Date command returns 11/05/09, strftime returns 05/11/09

----------
components: Library (Lib)
messages: 87582
nosy: jonathan.cervidae
severity: normal
status: open
title: strftime is broken
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon May 11 23:24:19 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 11 May 2009 21:24:19 +0000
Subject: [New-bugs-announce] [issue5998] Add __bool__ to threading.Event and
	multiprocessing.Event
In-Reply-To: <1242077059.81.0.31819803999.issue5998@psf.upfronthosting.co.za>
Message-ID: <1242077059.81.0.31819803999.issue5998@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

I think it would allow for more pythonic code if the threading.Event and
multiprocessing.Event classes had the __bool__ special attribute.  This
would allow doing "if e: ..." instead of "if e.is_set(): ...".

This could be backported to 2.x really easily by just replacing __bool__
to __nonzero__.

See also the thread starting here:
http://mail.python.org/pipermail/python-ideas/2009-May/004617.html

----------
components: Library (Lib)
files: event.diff
keywords: patch
messages: 87587
nosy: flub
severity: normal
status: open
title: Add __bool__ to threading.Event and multiprocessing.Event
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13959/event.diff

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

From report at bugs.python.org  Mon May 11 23:24:34 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 11 May 2009 21:24:34 +0000
Subject: [New-bugs-announce] [issue5999] compile error on HP-UX 11.22 ia64 -
	'mbstate_t' is used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>


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

cc +DD64 -Ae -D_REENTRANT +Z -c  -DNDEBUG -O  -I. -IInclude -I./Include
  -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
Error 419: "./Modules/python.c", line 34 # 'mbstate_t' is used as a
type, but has not been defined as a type.
            mbstate_t mbs;
            ^^^^^^^^^     
make: *** [Modules/python.o] Error 2


!
!
!

When I get time, I need to create a patch to fix this.. but if somebody
else already figured out what the issue is, that'd be great too.

----------
components: Build
messages: 87588
nosy: srid
severity: normal
status: open
title: compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Mon May 11 23:29:36 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 11 May 2009 21:29:36 +0000
Subject: [New-bugs-announce] [issue6000] compile error on AIX and HP-UX
	11.00 -	PyNumber_InPlaceOr(newfree, allfree) < 0
In-Reply-To: <1242077376.02.0.0771878872904.issue6000@psf.upfronthosting.co.za>
Message-ID: <1242077376.02.0.0771878872904.issue6000@psf.upfronthosting.co.za>


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

cc_r -qlanglvl=ansi -c  -DNDEBUG -O  -I. -IInclude -I./Include  
-DPy_BUILD_CORE -o Python/symtable.o Python/symtable.c
"Python/symtable.c", line 767.50: 1506-068 (S) Operation between types
"struct _object*" and "int" is not allowed.
"Python/symtable.c", line 826.55: 1506-068 (S) Operation between types
"struct _object*" and "int" is not allowed.
make: *** [Python/symtable.o] Error 1

!
!
!

The lines causing the error is:

	if (PyNumber_InPlaceOr(newfree, allfree) < 0)
		goto error;

...

	if (PyNumber_InPlaceOr(child_free, temp_free) < 0)
		goto error;


!
!
!

On HP-UX 11.00 (parisc and parisc2.0), the error message is:

cc +DAportable -Ae -D_REENTRANT +Z -c  -DNDEBUG -O  -I. -IInclude
-I./Include   -DPy_BUILD_CORE -o Python/symtable.o Python/symtable.c
cc: "Python/symtable.c", line 767: error 1649: Illegal integer-pointer
combination for <.
cc: "Python/symtable.c", line 767: error 1563: Expression in if must be
scalar.
cc: "Python/symtable.c", line 826: error 1649: Illegal integer-pointer
combination for <.
cc: "Python/symtable.c", line 826: error 1563: Expression in if must be
scalar.
make: *** [Python/symtable.o] Error 1


!
!
!

When I get time, I need to create a patch to fix this.. but if somebody
else already figured out what the issue is, that'd be great too.

----------
components: Build
messages: 87589
nosy: srid
severity: normal
status: open
title: compile error on AIX and HP-UX 11.00 - PyNumber_InPlaceOr(newfree, allfree) < 0
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Mon May 11 23:40:42 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 May 2009 21:40:42 +0000
Subject: [New-bugs-announce] [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>


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

Attached is a patch that implements test discovery for unittest.

It includes command line argument handling (awkward manual handling but
works fine...), so that it can be invoked through:

   python -m unittest discover
   python -m unittest discover start_dir pattern top_level_dir

If the patch is acceptable then I will write docs. Do I need to make a
post to Python-dev or is it ok to have it reviewed here? The basic
mechanism was hammered out on the Testing-in-Python mailing list with a
lot of input from Robert Collins.

Brett Cannon has already looked over the test discovery code (not the
command line handling code though!).

It includes a customization hook both for modules and packages to
customize test loading and discovery. Described below:

Advantage of this: it is simple (easy to extend)
Disadvantage: it is simple (a lot it doesn't do)

Test discovery is provided through the TestLoader.discover method.

It takes three arguments - start directory, pattern to match test files
(defaults to 'test*.py') and the top level directory of the project
(defaults to the start directory).

The main restriction is that all your tests must be importable from the
top level directory of your project. The start directory is then
recursively searched for files and packages that match the pattern you
pass in. Tests are loaded from matching modules, and all tests run.

(A further restriction is that discovery only currently recognises
packages as directories containing __init__.py files and not .pyc etc.)

The load_tests protocol provides a way for packages and modules to
customize test loading. This is inspired by a similar system in use in
the Bzr test suite.

Iff a test module defines a load_tests function then
TestLoader.loadTestsFromModule will call this function with loader,
tests, None. This should return a suite.

An example 'do nothing' implementation of load_tests would be:

   def load_tests(loader, tests, pattern):
       return tests

If a package directory name matches the pattern you pass into discovery
and the __init__.py contains a load_tests function then it will be
called with loader, tests, pattern. No further discovery will be done
into the package, but because it is passed the pattern as an argument it
is free to continue discovery itself. A do nothing load_tests for a
package is:

    def load_tests(loader, tests, pattern):
        if pattern is None:
            return tests
        return TestSuite(tests,
loader.discover(os.path.dirname(os.path.abspath(__file__)), pattern))

(The loader stores the top level directory it was originally called with
specifically for this use case. load_tests should not pass in a new top
level directory to the existing loader but create a new loader if it
wants to do this.)

Discovery does not follow the __path__ attribute of packages / modules
and only looks at the filesystem.

I have tested this implementation on the importlib tests (as one
example) and it worked fine.

Many of the restrictions mentioned here would be very easy to solve in
the future, but I think it is important to get some simple version of
test discovery in ASAP.

All I can think of for now...

----------
assignee: michael.foord
components: Library (Lib)
files: test_discovery.patch
keywords: needs review, patch, patch
messages: 87591
nosy: benjamin.peterson, michael.foord
severity: normal
stage: patch review
status: open
title: Test discovery for unittest
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13961/test_discovery.patch

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

From report at bugs.python.org  Tue May 12 00:33:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 May 2009 22:33:55 +0000
Subject: [New-bugs-announce] [issue6002] test_urlllib2_localnet
	DigestAuthHandler leaks nonces
In-Reply-To: <1242081235.08.0.896974873294.issue6002@psf.upfronthosting.co.za>
Message-ID: <1242081235.08.0.896974873294.issue6002@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I tracked down the exact cause of the refleak in test_urllib2_localnet.
 Turns out the DigestAuthHandler adds a nonce to its internal _nonces
list every time _return_auth_challenge is called, but not all of these
nonces are removed from the list.

Not sure what the cleanest fix would be.  I'm not that familiar with
auth protocols; I'm guessing a real auth server would time out stale
nonces.  One question I have is if the tests are expecting that the
nonce will get deleted, and thus there is a real bug here...but I
suspect not.

Adding

   FakeProxyHandler.digest_auth_handler._nonces = []

to the tearDown for ProxyAuthTests fixes the leak.  Is this acceptable,
or does this merit further investigation?

----------
components: Tests
keywords: easy
messages: 87593
nosy: r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: test_urlllib2_localnet DigestAuthHandler leaks nonces
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 12 11:36:46 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 May 2009 09:36:46 +0000
Subject: [New-bugs-announce] [issue6003] ZipFile.writestr "compression_type"
	argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Class zipfile.ZipFile has two methods for adding data to a zipfile: 
'write' and 'writestr'.

The former has a "compression_type" argument that can be used to specify 
the compression to be used. That latter doesn't have that argument.

Could a "compression_type" argument be added to "writestr" as well? I 
regularly create zipfiles from scratch using the writestr method to add 
content and currently have to modify the 'compression' attribute of the 
zipfile object to control compression and that leads to ugly code.

The other alternative is to use a ZipInfo object as the archive-name of 
the newly added file, but that leads to even uglier code.

----------
messages: 87610
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: ZipFile.writestr "compression_type" argument
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 12 11:36:50 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 May 2009 09:36:50 +0000
Subject: [New-bugs-announce] [issue6004] ZipFile.writestr "compression_type"
	argument
In-Reply-To: <1242121010.51.0.200108534181.issue6004@psf.upfronthosting.co.za>
Message-ID: <1242121010.51.0.200108534181.issue6004@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Class zipfile.ZipFile has two methods for adding data to a zipfile: 
'write' and 'writestr'.

The former has a "compression_type" argument that can be used to specify 
the compression to be used. That latter doesn't have that argument.

Could a "compression_type" argument be added to "writestr" as well? I 
regularly create zipfiles from scratch using the writestr method to add 
content and currently have to modify the 'compression' attribute of the 
zipfile object to control compression and that leads to ugly code.

The other alternative is to use a ZipInfo object as the archive-name of 
the newly added file, but that leads to even uglier code.

----------
messages: 87611
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: ZipFile.writestr "compression_type" argument
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 12 16:19:05 2009
From: report at bugs.python.org (Mads Kiilerich)
Date: Tue, 12 May 2009 14:19:05 +0000
Subject: [New-bugs-announce] [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

http://docs.python.org/library/socket.html says about socket.send:
"Applications are responsible for checking that all data has been sent;
if only some of the data was transmitted, the application needs to
attempt delivery of the remaining data."

And about socket.sendall:
"Unlike send(), this method continues to send data from string until
either all data has been sent or an error occurs."

However, the examples on the same page uses plain conn.send(data)
without checking anything. That is misleading.

A solution could be to use conn.sendall(data) instead.

----------
assignee: georg.brandl
components: Documentation
messages: 87633
nosy: georg.brandl, kiilerix
severity: normal
status: open
title: Bug in socket example
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue May 12 19:11:54 2009
From: report at bugs.python.org (Ely Eshel)
Date: Tue, 12 May 2009 17:11:54 +0000
Subject: [New-bugs-announce] [issue6006] ffi.c compile failures on AIX 5.3
	with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>


New submission from Ely Eshel <elyeshel at gmail.com>:

Building Python 3.0.1 with xlc on AIX 5.3, The following compiler 
errros come up:
/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 141.25: 1506-045 
(S) Undeclared identifier FFI_LINUX_SOFT_FLOAT.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 601.19: 1506-045 
(S) Undeclared identifier FFI_LINUX_SOFT_FLOAT.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 604.19: 1506-045 
(S) Undeclared identifier FFI_LINUX64.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 668.23: 1506-045 
(S) Undeclared identifier FFI_SYSV.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 902.10: 1506-045 
(S) Undeclared identifier FFI_SYSV.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 902.10: 1506-051 
(S) Case expression must be a valid integral constant.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 903.10: 1506-045 
(S) Undeclared identifier FFI_GCC_SYSV.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 903.10: 1506-051 
(S) Case expression must be a valid integral constant.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 904.10: 1506-045 
(S) Undeclared identifier FFI_LINUX.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 904.10: 1506-051 
(S) Case expression must be a valid integral constant.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 905.10: 1506-045 
(S) Undeclared identifier FFI_LINUX_SOFT_FLOAT.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 905.10: 1506-051 
(S) Case expression must be a valid integral constant.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 1027.26: 1506-045 
(S) Undeclared identifier FFI_SYSV.
"/home11/eeshel/dev/python/Python-
3.0.1/Modules/_ctypes/libffi/src/powerpc/ffi.c", line 1152.27: 1506-045 
(S) Undeclared identifier FFI_LINUX_SOFT_FLOAT.

Configuration command was:
configure --prefix=/home/eeshel/bin/python/python-3.0.1 --exec-
prefix=/home/eeshel/bin/python/python-3.0.1/ibm --with-
gcc="/bb/util/version10-022009/usr/vacpp/bin/xlc_r -Wl,-G" --with-
cxx="/bb/util/version10-022009/usr/vacpp/bin/xlc_r -Wl,-G" --disable-
ipv6 --disable-shared --with-threads

----------
assignee: theller
components: ctypes
messages: 87642
nosy: elyeshel, theller
severity: normal
status: open
title: ffi.c compile failures on AIX 5.3 with xlc
versions: Python 3.0

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

From report at bugs.python.org  Tue May 12 23:45:43 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 12 May 2009 21:45:43 +0000
Subject: [New-bugs-announce] [issue6007] distutils tricks you into thinking
	you can build	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Per issue3308, it is not really possible to build Python extensions with
MinGW anymore (as far as I can tell).  The distutils documentation is
misleading in this regard, as is the continued existence of the
build_ext --compiler=mingw32 option.  The result of using this feature
is a dll which cannot actually be loaded.

If my understanding of the issue is correct, then the mingw32 compiler
should be removed from distutils and the documentation corrected to
indicate the lack of support for this compiler toolchain.

----------
assignee: tarek
components: Distutils, Documentation, Library (Lib), Windows
messages: 87660
nosy: exarkun, tarek
severity: normal
status: open
title: distutils tricks you into thinking you can build extensions with mingw
versions: Python 2.6

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

From report at bugs.python.org  Wed May 13 02:49:53 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 13 May 2009 00:49:53 +0000
Subject: [New-bugs-announce] [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: <1242175792.97.0.077794043098.issue6008@psf.upfronthosting.co.za>


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

In Python2.x, Idle is installed as idle2.x. This is the case with Linux
and Mac.

However, in Py3.1b2, Idle is installed as `idle3`. 

Expected script name is `idle3.1`.

----------
components: IDLE
messages: 87664
nosy: srid
severity: normal
status: open
title: Idle should be installed as `idle3.1` and not `idle3`
versions: Python 3.1

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

From martin at v.loewis.de  Wed May 13 05:03:33 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 13 May 2009 05:03:33 +0200
Subject: [New-bugs-announce] [issue6007] distutils tricks you into
 thinking you can build	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
References: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <4A0A3885.5020606@v.loewis.de>

> Per issue3308, it is not really possible to build Python extensions with
> MinGW anymore (as far as I can tell).

I'm interpreting the issue differently - it was withdrawn by the
submitter, indicating that it isn't an issue with Python.

Even though I still don't understand the original issue, apparently,
it is an issue only if the localtime() function is used. Extensions
that don't use it might still work fine, according to the report.

> If my understanding of the issue is correct, then the mingw32 compiler
> should be removed from distutils and the documentation corrected to
> indicate the lack of support for this compiler toolchain.

I think this is exaggerating the actual state. The compiler is certainly
supported.

From report at bugs.python.org  Wed May 13 07:02:07 2009
From: report at bugs.python.org (Vaibhav Mallya)
Date: Wed, 13 May 2009 05:02:07 +0000
Subject: [New-bugs-announce] [issue6009] optparse docs say 'default' keyword
	is deprecated but	uses it in most examples
In-Reply-To: <1242190926.0.0.968913791867.issue6009@psf.upfronthosting.co.za>
Message-ID: <1242190926.0.0.968913791867.issue6009@psf.upfronthosting.co.za>


New submission from Vaibhav Mallya <mallyvai at umich.edu>:

The first example, and several subsequent examples later on in the
optparse docs, use 'default' as an argument, even though it's apparently
deprecated in favor of set_defaults. At the risk of overstating the
obvious, this seems to be inconsistent. Even the section on defaults
http://docs.python.org/library/optparse.html#default-values uses the
'default' keyword without stressing its deprecation. It might make more
sense to leave it out of all of the examples altogether, replacing it
with the appropriate set_defaults invocations.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 87668
nosy: georg.brandl, mallyvai
severity: normal
status: open
title: optparse docs say 'default' keyword is deprecated but uses it in most examples
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May 13 12:35:08 2009
From: report at bugs.python.org (izarf)
Date: Wed, 13 May 2009 10:35:08 +0000
Subject: [New-bugs-announce] [issue6010] unable to retrieve latin-1 encoded
	data from sqlite3
In-Reply-To: <1242210908.7.0.745434418713.issue6010@psf.upfronthosting.co.za>
Message-ID: <1242210908.7.0.745434418713.issue6010@psf.upfronthosting.co.za>


New submission from izarf <izarf.mail at gmail.com>:

it is impossible to retrieve a latin-1 encoded string from sqlite3 database.

How to:
1. create a new db.
2. create a new table with text field.
3. insert a row with data like "???"

4. select all rows from table
5. write:
     for data in cursor1:
           var = data

you will now get an error explaining something like ascii couldn't decode

----------
components: None
messages: 87672
nosy: izarf
severity: normal
status: open
title: unable to retrieve latin-1 encoded data from sqlite3
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed May 13 13:01:50 2009
From: report at bugs.python.org (Baptiste Carvello)
Date: Wed, 13 May 2009 11:01:50 +0000
Subject: [New-bugs-announce] [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: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>


New submission from Baptiste Carvello <baptiste13z at free.fr>:

I have tried to build python (version 3.1 beta 1) on linux and install
it to a non-standard prefix which contains non-ascii utf-8 characters
(my locale being utf-8). The build directory's path is ascii-only. The
exact configure line is given in the attached file 'tb.txt'.

Then the 'make' command fails at the stage where python extensions are
built, with the traceback displayed in file tb.txt (in short:
UnicodeDecodeError: 'ascii' codec can't decode byte ... ).

The problem is triggered when 'distutils.sysconfig.get_config_vars'
tries to parse the Makefile. The Makefile is opened with
'distutils.text_file.TextFile', which in turns calls 'io.open' with no
'encoding' parameter. At this stage of the build, the 'locale' module is
not available (due to '_collections' not being), so that
'locale.getprefferedencoding' cannot be called and the encoding falls
back to ascii (a quick look to 'Modules/_io/textio.c' suggests that this
fallback mechanism is already designed for being used at build time).

The solution I propose would be to use 'sys.getfilesystemencoding' as a
fallback first, as it is defined during build time on most systems:
windows, mac and on posix if 'CODESET' exists in 'langinfo.h'. Given
that in build routines, non-ascii characters are only likely to be
encountered in filesystem paths, this seems a reasonable behavior.

The attached patch 'text_file.diff' implements this strategy in
'distutils.text_file', and then calls 'io.open' with the appropriate
'encoding' parameter. It could be argued, however, that this new
fallback is of general interest and should be implemented directly in
'Modules/_io/textio.c'. If you deem so, I could try to come up with a
new patch.

The attached patch solves the problem on my system, and does not
introduce test failures (which is expected, as the new fallback should
only make a difference at build time).

Cheers,
Baptiste

----------
assignee: tarek
components: Distutils
files: tb.txt
messages: 87674
nosy: tarek, zegreek
severity: normal
status: open
title: python doesn't build if prefix contains non-ascii characters
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13974/tb.txt

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

From report at bugs.python.org  Wed May 13 13:46:20 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 May 2009 11:46:20 +0000
Subject: [New-bugs-announce] [issue6012] enhance getargs O& to accept
	cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>


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

This issue comes from #5990.

Currently, O& doesn't accept general cleanup function. This causes
memory leak sometimes. Here is an experimental patch to create new
format O&& similar to O& but have general cleanup function.

----------
components: Interpreter Core
files: experimental_getargs_with_cleanup.patch
keywords: patch
messages: 87677
nosy: ocean-city
severity: normal
status: open
title: enhance getargs O& to accept cleanup function
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13976/experimental_getargs_with_cleanup.patch

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

From report at bugs.python.org  Wed May 13 16:33:01 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 13 May 2009 14:33:01 +0000
Subject: [New-bugs-announce] [issue6013] json slower than simplejson
In-Reply-To: <1242225181.83.0.814831398624.issue6013@psf.upfronthosting.co.za>
Message-ID: <1242225181.83.0.814831398624.issue6013@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

The json package is a lot slower than the simplejson package.  Both
packages have their C compiled speedup module; however:

  C:\>py26 -m timeit -s "from json import dumps, loads"
"loads(dumps(range(32)))"
  1000 loops, best of 3: 618 usec per loop

  C:\>py26 -m timeit -s "from simplejson import dumps, loads"
"loads(dumps(range(32)))"
  10000 loops, best of 3: 31 usec per loop

This is on Windows XP, with Python 2.6.2.

----------
messages: 87685
nosy: theller
severity: normal
status: open
title: json slower than simplejson
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Thu May 14 00:01:25 2009
From: report at bugs.python.org (Ralf Seliger)
Date: Wed, 13 May 2009 22:01:25 +0000
Subject: [New-bugs-announce] [issue6014] No shell prompt when a graphics
	that was started from	IDLE is closed
In-Reply-To: <1242252085.07.0.824128250707.issue6014@psf.upfronthosting.co.za>
Message-ID: <1242252085.07.0.824128250707.issue6014@psf.upfronthosting.co.za>


New submission from Ralf Seliger <admin at kreidestaub.de>:

Platform: Ubuntu 8.10

Affected versions: Python 2.6.2, IDLE 2.6.2 and Python 2.5.4, IDLE 1.2.4

>From IDLE I run a program that opens a graphics window (e.g. using the
Natural Language Toolkit: >>> import nltk followed by >>> nltk.download()). 

When I close the graphics window, I expect to be able to continue
working with the Python shell.

What happens instead is this: The graphics window closes, but the shell
prompt (>>>) does not appear. It seems the subprocess responsible for
the graphics window is still running even though the window is no more. 

All I can do is close IDLE upon which it complains about a program that
is still running.

I am not sure whether this is an IDLE-bug, a graphics package bug or a
nltk-bug,

----------
components: IDLE
messages: 87715
nosy: chessweb
severity: normal
status: open
title: No shell prompt when a graphics that was started from IDLE is closed
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 14 01:01:54 2009
From: report at bugs.python.org (Jerome)
Date: Wed, 13 May 2009 23:01:54 +0000
Subject: [New-bugs-announce] [issue6015] Scrollbar in Idle os x 10.5
In-Reply-To: <1242255714.91.0.667692922857.issue6015@psf.upfronthosting.co.za>
Message-ID: <1242255714.91.0.667692922857.issue6015@psf.upfronthosting.co.za>


New submission from Jerome <knappjt at yahoo.com>:

Hi, when I try to use the scrollbar to scroll through the REPL window or 
through a file I'm editing with IDLE in os x 10.5 the image of the 
scroll bar doesn't seem to correspond to anything, it moves more or less 
than my mouse when I'm trying to use it, and sometimes I can't click on 
it at all.  Also, clicking in the empty space to move forward or back a 
page doesn't always work.

~~

Also, I can't scroll the idle window with OS X's built in trackpad 
scrolling feature.  Maybe this isn't a bug thought, is it because idle 
is built with tkinter or something and for this feature to work it needs 
to be built with some os x tool?

----------
components: IDLE
messages: 87721
nosy: an is
severity: normal
status: open
title: Scrollbar in Idle os x 10.5
versions: Python 3.1

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

From report at bugs.python.org  Thu May 14 04:05:48 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 14 May 2009 02:05:48 +0000
Subject: [New-bugs-announce] [issue6016] Use shipped zlib if the system
	version is bad
In-Reply-To: <1242266748.56.0.906983355468.issue6016@psf.upfronthosting.co.za>
Message-ID: <1242266748.56.0.906983355468.issue6016@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The attached patch makes setup.py use the shipped zlib.h in
Modules/zlib/ when a bogus zlib.h is found by find_file.

However, I couldn't test it (nor make it work) when a system zlib is
missing (no time right now). Can we build the shipped zlib and link
against it?

----------
components: Build
files: zlib_setup.diff
keywords: patch, patch
messages: 87727
nosy: ajaksu2
priority: normal
severity: normal
stage: test needed
status: open
title: Use shipped zlib if the system version is bad
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13980/zlib_setup.diff

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

From report at bugs.python.org  Thu May 14 07:44:04 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 14 May 2009 05:44:04 +0000
Subject: [New-bugs-announce] [issue6017] Dict fails to notice addition and
	deletion of keys during	iteration
In-Reply-To: <1242279843.94.0.529178267811.issue6017@psf.upfronthosting.co.za>
Message-ID: <1242279843.94.0.529178267811.issue6017@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

I'm not sure if this is a documentation bug or a behaviour bug, or 
possibly both.

The documentation warns about adding or deleting items from a dict 
while iterating over it:

"Using iteritems() while adding or deleting entries in the dictionary 
will raise a RuntimeError."

http://docs.python.org/library/stdtypes.html#dict.iteritems

Same for other dict iterators.

However, you can add and delete items, so long as the overall size of 
the dict doesn't change. Consequently, some modifications to the dict 
aren't caught, leading to various misbehaviour in (at least) Python 
2.5 and 2.6.

Some dicts appear to "run too long":

>>> d = dict(x=3, y=4)  # Two items
>>> it = d.iteritems()
>>> it.next()  # One
('y', 4)
>>> del d['y']
>>> d['z'] = 5
>>> it.next()  # Two
('x', 3)
>>> it.next()  # Three
('z', 5)


While others run too short:

>>> d = {-1: 'aa', -2: 'bb'}  # Two items
>>> it = d.iteritems()
>>> it.next()  # One
(-2, 'bb')
>>> del d[-1]
>>> d[0] = 'cc'
>>> it.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 87729
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: Dict fails to notice addition and deletion of keys during iteration
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Thu May 14 12:06:42 2009
From: report at bugs.python.org (Retro)
Date: Thu, 14 May 2009 10:06:42 +0000
Subject: [New-bugs-announce] [issue6018] Fix the output word from "ok" to
	"OK" when a testcase	passes
In-Reply-To: <1242295602.1.0.308241419515.issue6018@psf.upfronthosting.co.za>
Message-ID: <1242295602.1.0.308241419515.issue6018@psf.upfronthosting.co.za>


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

you at localhost:~$ python3 romantest1.py -v
to_roman should give known result with known input ... ok

Better would be:
you at localhost:~$ python3 romantest1.py -v
to_roman should give known result with known input ... OK

Since other words are capitalized, this one should be, too. Please fix that.

----------
components: None
messages: 87732
nosy: Retro
severity: normal
status: open
title: Fix the output word from "ok" to "OK"  when a testcase passes
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu May 14 12:41:24 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 14 May 2009 10:41:24 +0000
Subject: [New-bugs-announce] [issue6019] Minor typos in ctypes docs
In-Reply-To: <1242297684.85.0.343298807561.issue6019@psf.upfronthosting.co.za>
Message-ID: <1242297684.85.0.343298807561.issue6019@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

There are a few errors in the ctypes documentation covering function
calls using the example of `libc.printf`. It's basically just typos but
they are really confusing when trying to understand the examples.

Patch to trunk is attached. Corrections should apply to 3.x as well but
I'm unsure whether they apply cleanly to those branches, see issue4309
for details.

Unicode coercion as in printf("%S", u"abc") keeps segfaulting for me
with 2.5 so I'm unsure about the example's validity there; corrections
could be backported to 2.5-maint as well though. 2.4 and below are not
affected: ctypes was not present in these versions.

----------
assignee: georg.brandl
components: Documentation
files: ctypes-docs.patch
keywords: patch
messages: 87733
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Minor typos in ctypes docs
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file13981/ctypes-docs.patch

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

From report at bugs.python.org  Thu May 14 18:57:57 2009
From: report at bugs.python.org (Matthew Wilson)
Date: Thu, 14 May 2009 16:57:57 +0000
Subject: [New-bugs-announce] [issue6020] Create a
	datetime.timedelta.totalseconds property
In-Reply-To: <1242320277.61.0.875644681622.issue6020@psf.upfronthosting.co.za>
Message-ID: <1242320277.61.0.875644681622.issue6020@psf.upfronthosting.co.za>


New submission from Matthew Wilson <matt at tplus1.com>:

I do this kind of thing a lot:

>>> from datetime import timedelta
>>> td = timedelta(days=2, seconds=14)
>>> total_duration_in_seconds = td.days * 24 * 60 * 60 + td.seconds

I would like to have a property on the timedelta object do this for me.

----------
components: Library (Lib)
messages: 87741
nosy: mw44118
severity: normal
status: open
title: Create a datetime.timedelta.totalseconds property
versions: Python 2.7

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

From report at bugs.python.org  Thu May 14 19:05:31 2009
From: report at bugs.python.org (Lie Ryan)
Date: Thu, 14 May 2009 17:05:31 +0000
Subject: [New-bugs-announce] [issue6021] itertools.grouper
In-Reply-To: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za>
Message-ID: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za>


New submission from Lie Ryan <lie.1296 at gmail.com>:

An itertool to Group-by-n 

>>> lst = range(15)
>>> itertools.grouper(lst, 5)
[[0, 1, 2, 3, 4], [5, 6, 7, 8, 9], [10, 11, 12, 13, 14]]

This function is often asked in several c.l.py discussions, such as these: 
http://comments.gmane.org/gmane.comp.python.general/623377
http://comments.gmane.org/gmane.comp.python.general/622763

There are several issues. What should be done if the number of items in
the original list is not exactly divisible?
- raise an error as default
- pad with a value from 3rd argument
- make the last one shorter, maybe using keyword arguments or sentinel
to 3rd argument

or should there be separate functions for each of them?

What about infinite list? Most recipes for the function uses zip which
breaks with infinite list.

----------
components: Library (Lib)
messages: 87743
nosy: lieryan
severity: normal
status: open
title: itertools.grouper
type: feature request

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

From report at bugs.python.org  Thu May 14 19:05:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 May 2009 17:05:57 +0000
Subject: [New-bugs-announce] [issue6022] test_distutils leaves a 'foo' file
	behind in the cwd
In-Reply-To: <1242320757.03.0.676564730728.issue6022@psf.upfronthosting.co.za>
Message-ID: <1242320757.03.0.676564730728.issue6022@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The test for issue #5977 added to test_get_outputs leaves a file named
'foo' behind in the current working directory.

----------
messages: 87744
nosy: r.david.murray
severity: normal
status: open
title: test_distutils leaves a 'foo' file behind in the cwd

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

From report at bugs.python.org  Thu May 14 21:00:02 2009
From: report at bugs.python.org (Jonathan Hayward)
Date: Thu, 14 May 2009 19:00:02 +0000
Subject: [New-bugs-announce] [issue6023] Search does not intelligently
	handle module.function	queries on docs.python.org
In-Reply-To: <1242327602.66.0.211164377671.issue6023@psf.upfronthosting.co.za>
Message-ID: <1242327602.66.0.211164377671.issue6023@psf.upfronthosting.co.za>


New submission from Jonathan Hayward <jonathan.hayward at pobox.com>:

The search function on docs.python.org does not intelligently search the
library for a query in the form "module.function". For instance, in
searching for information on (say) socket.bind(), neither a search query
of "socket.bind()" nor "socket.bind" finds any results. I need to search
for "socket bind" / "bind socket" to get results (or possibly "socket"
or "bind" alone to get a larger number of less focused results.) This is
particularly interesting as the page I am interested in contains the
string "socket.bind" and in fact the snippet that appears on the search
result page for the #1 match is: "...onnection, and *address* is the
address bound to the socket on the other end of the connection. ..
method:: socket.bind(address) Bind the socket to *address*. The socket
must not already be bound. (The format of *address* depen..."

It would be nice if searches for module.function, module.CONSTANT,
module.object, module.object.function, etc. would work for search terms
as objects are named in the API.

(A much easier, if imperfect approximation, would be to treat \W as
breaking words as spaces are treated now, so that e.g. periods in
queries would be internally treated as spaces and a search for
"socket.bind" would be treated as "socket bind" and possibly get
surprisingly good results; see
http://docs.python.org/search.html?q=socket+bind .)

Jonathan
http://JonathansCorner.com/

----------
assignee: georg.brandl
components: Documentation
messages: 87755
nosy: JonathansCorner.com, georg.brandl
severity: normal
status: open
title: Search does not intelligently handle module.function queries on docs.python.org

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

From report at bugs.python.org  Fri May 15 00:28:32 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 14 May 2009 22:28:32 +0000
Subject: [New-bugs-announce] [issue6024] regrtest says refleaks are "ok"
In-Reply-To: <1242340112.88.0.36043966948.issue6024@psf.upfronthosting.co.za>
Message-ID: <1242340112.88.0.36043966948.issue6024@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

Currently (r72643), regrtest.py -R:: says that a test passed even if it
leaked references:

trunk collinwinter$ ./python.exe Lib/test/regrtest.py -R::
test_urllib2_localnet
test_urllib2_localnet
beginning 9 repetitions
123456789
.........
test_urllib2_localnet leaked [3, 3, 3, 3] references, sum=12
1 test OK.
[50020 refs]
trunk collinwinter$

The attached patch turns that into

trunk collinwinter$ ./python.exe Lib/test/regrtest.py -R::
test_urllib2_localnet
test_urllib2_localnet
beginning 9 repetitions
123456789
.........
test_urllib2_localnet leaked [3, 3, 3, 3] references, sum=12
1 test failed:
    test_urllib2_localnet
[50010 refs]
trunk collinwinter$ echo $?
1
trunk collinwinter$

This makes it easier to run regrtest.py -R:: as part of a buildbot
installation.

I'll merge to py3k once this is reviewed. Any thoughts on merging to
release26-maint?

----------
components: Tests
files: refleak.patch
keywords: patch
messages: 87776
nosy: collinwinter, jyasskin
severity: normal
stage: patch review
status: open
title: regrtest says refleaks are "ok"
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13985/refleak.patch

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

From report at bugs.python.org  Fri May 15 01:46:18 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Thu, 14 May 2009 23:46:18 +0000
Subject: [New-bugs-announce] [issue6025] documentation of
	xml.dom.minidom.parse signature is wrong
In-Reply-To: <1242344778.1.0.605292139005.issue6025@psf.upfronthosting.co.za>
Message-ID: <1242344778.1.0.605292139005.issue6025@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister <phihag at phihag.de>:

In the documentation, the signature is given as parse(filename_or_file,
parser), although the next paragraph reads "(...) *parser*, if given,
(...)".

The latter is correct, and there is a new bufsize parameter, too.

----------
assignee: georg.brandl
components: Documentation, XML
files: xml-minidom-parse-signature-doc.diff
keywords: patch
messages: 87781
nosy: georg.brandl, phihag
severity: normal
status: open
title: documentation of xml.dom.minidom.parse signature is wrong
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file13987/xml-minidom-parse-signature-doc.diff

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

From report at bugs.python.org  Fri May 15 02:58:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 May 2009 00:58:26 +0000
Subject: [New-bugs-announce] [issue6026]
	test_(zipfile|zipimport|gzip|distutils) fail if zlib is	not
	available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Python build finished, but the necessary bits to build these modules
were not found: _dbm _gdbm _hashlib _sqlite3 _ssl _tkinter bz2 zlib


When zlib is missing some tests fail:

./python -m test.regrtest -uall -v test_zipimport
Could not find '/home/wolf/py3k/Lib/test' in sys.path to remove it
test_zipimport
test test_zipimport crashed -- <class 'ImportError'>: No module named zlib
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/regrtest.py", line 613, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/wolf/py3k/Lib/test/test_zipimport.py", line 9, in <module>
    import zlib # implied prerequisite
ImportError: No module named zlib
1 test failed:
    test_zipimport


./python -m test.regrtest -uall -v test_zipfile
Could not find '/home/wolf/py3k/Lib/test' in sys.path to remove it
test_zipfile
testAbsoluteArcnames (test.test_zipfile.TestsWithSourceFile) ... ok
[...]
 
======================================================================
ERROR: test_PerFileCompression (test.test_zipfile.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_zipfile.py", line 300, in
test_PerFileCompression
    zipfp.write(TESTFN, 'deflateme', zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 1045, in write
    self._writecheck(zinfo)
  File "/home/wolf/py3k/Lib/zipfile.py", line 1004, in _writecheck
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
======================================================================
ERROR: testGoodPassword (test.test_zipfile.DecryptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_zipfile.py", line 856, in
testGoodPassword
    self.assertEquals(self.zip2.read("zero"), self.plain2)
  File "/home/wolf/py3k/Lib/zipfile.py", line 850, in read
    return self.open(name, "r", pwd).read()
  File "/home/wolf/py3k/Lib/zipfile.py", line 923, in open
    zef = ZipExtFile(zef_file, zinfo, zd)
  File "/home/wolf/py3k/Lib/zipfile.py", line 470, in __init__
    self.dc = zlib.decompressobj(-15)
AttributeError: 'NoneType' object has no attribute 'decompressobj'
 
======================================================================
ERROR: testDifferentFile (test.test_zipfile.TestsWithMultipleOpens)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_zipfile.py", line 955, in setUp
    zipfp = zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 669, in __init__
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
======================================================================
ERROR: testInterleaved (test.test_zipfile.TestsWithMultipleOpens)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_zipfile.py", line 955, in setUp
    zipfp = zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 669, in __init__
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
======================================================================
ERROR: testSameFile (test.test_zipfile.TestsWithMultipleOpens)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_zipfile.py", line 955, in setUp
    zipfp = zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 669, in __init__
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
----------------------------------------------------------------------
Ran 53 tests in 1.292s
 
FAILED (errors=5)
test test_zipfile failed -- errors occurred; run in verbose mode for details
1 test failed:
    test_zipfile


./python -m test.regrtest -uall -v test_gzip
Could not find '/home/wolf/py3k/Lib/test' in sys.path to remove it
test_gzip
test test_gzip crashed -- <class 'ImportError'>: No module named zlib
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/regrtest.py", line 613, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/wolf/py3k/Lib/test/test_gzip.py", line 8, in <module>
    import gzip
  File "/home/wolf/py3k/Lib/gzip.py", line 9, in <module>
    import zlib
ImportError: No module named zlib
1 test failed:
    test_gzip


./python -m test.regrtest -uall -v test_distutils
Could not find '/home/wolf/py3k/Lib/test' in sys.path to remove it
test_distutils
test_check_all (distutils.tests.test_check.CheckTestCase) ... ok
[...]
 
======================================================================
ERROR: test_simple_built (distutils.tests.test_bdist_dumb.BuildDumbTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/distutils/tests/test_bdist_dumb.py", line
62, in test_simple_built
    cmd.run()
  File "/home/wolf/py3k/Lib/distutils/command/bdist_dumb.py", line 111,
in run
    self.format, root_dir=archive_root)
  File "/home/wolf/py3k/Lib/distutils/cmd.py", line 372, in make_archive
    dry_run=self.dry_run)
  File "/home/wolf/py3k/Lib/distutils/archive_util.py", line 160, in
make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/home/wolf/py3k/Lib/distutils/archive_util.py", line 97, in
make_zipfile
    compression=zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 669, in __init__
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
======================================================================
ERROR: test_add_defaults (distutils.tests.test_sdist.sdistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/distutils/tests/test_sdist.py", line 193, in
test_add_defaults
    cmd.run()
  File "/home/wolf/py3k/Lib/distutils/command/sdist.py", line 150, in run
    self.make_distribution()
  File "/home/wolf/py3k/Lib/distutils/command/sdist.py", line 464, in
make_distribution
    file = self.make_archive(base_name, fmt, base_dir=base_dir)
  File "/home/wolf/py3k/Lib/distutils/cmd.py", line 372, in make_archive
    dry_run=self.dry_run)
  File "/home/wolf/py3k/Lib/distutils/archive_util.py", line 160, in
make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/home/wolf/py3k/Lib/distutils/archive_util.py", line 97, in
make_zipfile
    compression=zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 669, in __init__
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
======================================================================
ERROR: test_prune_file_list (distutils.tests.test_sdist.sdistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/distutils/tests/test_sdist.py", line 100, in
test_prune_file_list
    cmd.run()
  File "/home/wolf/py3k/Lib/distutils/command/sdist.py", line 150, in run
    self.make_distribution()
  File "/home/wolf/py3k/Lib/distutils/command/sdist.py", line 464, in
make_distribution
    file = self.make_archive(base_name, fmt, base_dir=base_dir)
  File "/home/wolf/py3k/Lib/distutils/cmd.py", line 372, in make_archive
    dry_run=self.dry_run)
  File "/home/wolf/py3k/Lib/distutils/archive_util.py", line 160, in
make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/home/wolf/py3k/Lib/distutils/archive_util.py", line 97, in
make_zipfile
    compression=zipfile.ZIP_DEFLATED)
  File "/home/wolf/py3k/Lib/zipfile.py", line 669, in __init__
    "Compression requires the (missing) zlib module")
RuntimeError: Compression requires the (missing) zlib module
 
----------------------------------------------------------------------
Ran 108 tests in 0.739s
 
FAILED (errors=3)
test test_distutils failed -- errors occurred; run in verbose mode for
details
1 test failed:
    test_distutils


Should these tests be skipped instead?

----------
components: Tests
messages: 87783
nosy: ezio.melotti
severity: normal
status: open
title: test_(zipfile|zipimport|gzip|distutils) fail if zlib is not available
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri May 15 03:34:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 May 2009 01:34:26 +0000
Subject: [New-bugs-announce] [issue6027] test_xmlrpc_net fails when the ISP
	returns "302 Found"
In-Reply-To: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za>
Message-ID: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

./python -m test.regrtest -uall -v test_xmlrpc_net
Could not find '/home/wolf/py3k/Lib/test' in sys.path to remove it
test_xmlrpc_net
test_current_time (test.test_xmlrpc_net.CurrentTimeTest) ... ERROR
 
======================================================================
ERROR: test_current_time (test.test_xmlrpc_net.CurrentTimeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_xmlrpc_net.py", line 18, in
test_current_time
    t0 = server.currentTime.getCurrentTime()
  File "/home/wolf/py3k/Lib/xmlrpc/client.py", line 1091, in __call__
    return self.__send(self.__name, args)
  File "/home/wolf/py3k/Lib/xmlrpc/client.py", line 1333, in __request
    verbose=self.__verbose
  File "/home/wolf/py3k/Lib/xmlrpc/client.py", line 1127, in request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for time.xmlrpc.com/RPC2:
302 Found>
 
----------------------------------------------------------------------
Ran 1 test in 0.148s
 
FAILED (errors=1)
test test_xmlrpc_net failed -- Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_xmlrpc_net.py", line 18, in
test_current_time
    t0 = server.currentTime.getCurrentTime()
  File "/home/wolf/py3k/Lib/xmlrpc/client.py", line 1091, in __call__
    return self.__send(self.__name, args)
  File "/home/wolf/py3k/Lib/xmlrpc/client.py", line 1333, in __request
    verbose=self.__verbose
  File "/home/wolf/py3k/Lib/xmlrpc/client.py", line 1127, in request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for time.xmlrpc.com/RPC2:
302 Found>
 
1 test failed:
    test_xmlrpc_net


Apparently the error was raised because:
1) time.xmlrpc.com wasn't reachable
2) the ISP (not the browser) returned a "302 Found" and an error page
3) the test expected something else and failed

This is somewhat related to #3583.

----------
components: Tests
messages: 87785
nosy: ezio.melotti
severity: normal
status: open
title: test_xmlrpc_net fails when the ISP returns "302 Found"
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri May 15 10:29:40 2009
From: report at bugs.python.org (Yury)
Date: Fri, 15 May 2009 08:29:40 +0000
Subject: [New-bugs-announce] [issue6028] Interpreter crashes when chaining
	an infinite number of	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>


New submission from Yury <yury.sobolev at gmail.com>:

def error_handle():
    try:
        print(5/0)
    except:
        error_handle()

error_handle()

Fatal Python error: Cannot recover from stack overflow.
Aborted

The interpreter should not crash. Perhaps a RuntimeError should be
thrown instead.

----------
components: Interpreter Core
messages: 87797
nosy: yury
severity: normal
status: open
title: Interpreter crashes when chaining an infinite number of exceptions
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Fri May 15 10:49:09 2009
From: report at bugs.python.org (Peter Bray)
Date: Fri, 15 May 2009 08:49:09 +0000
Subject: [New-bugs-announce] [issue6029] FAIL:
	test_longdouble	(ctypes.test.test_callbacks.Callbacks)
	[SPARC/64-bit]
In-Reply-To: <1242377349.19.0.984337506616.issue6029@psf.upfronthosting.co.za>
Message-ID: <1242377349.19.0.984337506616.issue6029@psf.upfronthosting.co.za>


New submission from Peter Bray <pdb_ml at yahoo.com.au>:

Greetings,

  I have downloaded and compiled Python 3.1b1 on Solaris 10 Update 6
with GCC 4.1.2 on {SPARC,x86} x {32-bit,64-bit} and encountered only one
test harness failure, which was on SPARC 64-bit.

  Included below are the initial details, is there something more I can
do to assist, if so, please be specific.

Regards,
Peter


./python Lib/test/regrtest.py -v test_ctypes

======================================================================
FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
    self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: First differing element 1:
0.0
3.14
- (-3, 0.0)
+ (-3, 3.14)

----------------------------------------------------------------------
Ran 328 tests in 3.853s

FAILED (failures=1)
test test_ctypes failed -- Traceback (most recent call last):
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
    self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: First differing element 1:
0.0
3.14
- (-3, 0.0)
+ (-3, 3.14)

1 test failed:
    test_ctypes

The test code (from Python-3.1b1/Lib/ctypes/test/test_callbacks.py)

    79  
    80      def test_longdouble(self):
    81          self.check_type(c_longdouble, 3.14)
    82          self.check_type(c_longdouble, -3.14)
    83  

and ealier in the same file

    11  
    12      def callback(self, *args):
    13          self.got_args = args
    14          return args[-1]
    15  
    16      def check_type(self, typ, arg):
    17          PROTO = self.functype.__func__(typ, typ)
    18          result = PROTO(self.callback)(arg)
    19          if typ == c_float:
    20              self.failUnlessAlmostEqual(result, arg, places=5)
    21          else:
    22              self.failUnlessEqual(self.got_args, (arg,))
    23              self.failUnlessEqual(result, arg)
    24  
    25          PROTO = self.functype.__func__(typ, c_byte, typ)
    26          result = PROTO(self.callback)(-3, arg)
    27          if typ == c_float:
    28              self.failUnlessAlmostEqual(result, arg, places=5)
    29          else:
    30              self.failUnlessEqual(self.got_args, (-3, arg))
    31              self.failUnlessEqual(result, arg)
    32  
 


[software at specula] 64-bit SPARC % gcc -v
Using built-in specs.
Target: sparc64-sun-solaris2.10
Configured with: ../configure --prefix=/pkgs/64-bit/release/gcc-4.1.2
--with-local-prefix=/pkgs/64-bit --disable-nls --disable-multilib
--enable-shared --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-gmp=/pkgs/64-bit
--with-mpfr=/pkgs/64-bit --enable-languages=c,c++,objc,obj-c++,fortran
sparc64-sun-solaris2.10
Thread model: posix
gcc version 4.1.2

[software at specula] 64-bit SPARC % cat /etc/release     
                      Solaris 10 10/08 s10s_u6wos_07b SPARC
           Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 27 October 2008

Build Procedure
---------------

Python 3.1b1

## Note PKGS_PREFIX=/pkgs/64-bit and PKGS_RELEASE=/pkgs/64-bit/release

gtar fxv <path>/Python-3.1b1.tar.bz2
cd Python-3.1b1

# The CPPFLAGS & LDFLAGS are used by setup.py in external modules builds
CPPFLAGS="-I${PKGS_PREFIX}/include" LDFLAGS="-L${PKGS_PREFIX}/lib"
./configure --prefix=${PKGS_RELEASE}/Python-3.1b1
--datarootdir=${PKGS_RELEASE}/Python-3.1b1 --with-universal-archs=64-bit 

echo "crypt cryptmodule.c" >> Modules/Setup.local  ## Solaris does not
need -lcrypt

gmake
gmake test

----------
assignee: theller
components: Tests, ctypes
messages: 87798
nosy: illumino, theller
severity: normal
status: open
title: FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri May 15 22:25:04 2009
From: report at bugs.python.org (Josh Roesslein)
Date: Fri, 15 May 2009 20:25:04 +0000
Subject: [New-bugs-announce] [issue6030] io.BufferedWriter C module missing
	_write_lock
In-Reply-To: <1242419104.2.0.221956700453.issue6030@psf.upfronthosting.co.za>
Message-ID: <1242419104.2.0.221956700453.issue6030@psf.upfronthosting.co.za>


New submission from Josh Roesslein <jroesslein at gmail.com>:

The C version of BufferedWriter is missing the _write_lock attribute.
I am not sure if there is a reason for this or it was left out by
accident. Python version still has the attribute.

----------
components: Extension Modules, IO, Library (Lib)
messages: 87831
nosy: jroesslein
severity: normal
status: open
title: io.BufferedWriter C module missing _write_lock
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat May 16 01:57:56 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 15 May 2009 23:57:56 +0000
Subject: [New-bugs-announce] [issue6031] BaseServer.shutdown documentation
	is incomplete
In-Reply-To: <1242431876.91.0.139343855315.issue6031@psf.upfronthosting.co.za>
Message-ID: <1242431876.91.0.139343855315.issue6031@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

BaseServer.shutdown is documented as "Tells the serve_forever() loop to 
stop and waits until it does."

The docstring is much more explicit: """Stops the serve_forever loop. 
Blocks until the loop has finished. This must be called while 
serve_forever() is running in another thread, or it will deadlock."""

Combined with #2302 I'd rewrite both (rst and docstring) as:

BaseServer.shutdown(): Tells the serve_forever() loop to stop, and 
waits until the loop has finished. This must be called after 
serve_forever() has started and while it is running in another thread, 
or the shutdown() call will deadlock."

----------
assignee: georg.brandl
components: Documentation
messages: 87845
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: BaseServer.shutdown documentation is incomplete
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May 16 02:47:14 2009
From: report at bugs.python.org (Collin Winter)
Date: Sat, 16 May 2009 00:47:14 +0000
Subject: [New-bugs-announce] [issue6032] Fix refleaks in
	test_urllib2_localnet
In-Reply-To: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>
Message-ID: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

Currently (r72673), test_urllib2_localnet leaks references. This is due
to state implicitly shared between tests. The attached patch fixes this
by removing the shared state.

The problem is also present in py3k. I'll port the patch once I commit
to trunk. Should this be backported so we can take test_urllib2_localnet
off the refleak test blacklist in Misc/build.sh in those branches?

----------
components: Tests
files: urllib2_localnet.patch
keywords: patch
messages: 87846
nosy: collinwinter
severity: normal
stage: patch review
status: open
title: Fix refleaks in test_urllib2_localnet
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13991/urllib2_localnet.patch

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

From report at bugs.python.org  Sat May 16 03:44:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 May 2009 01:44:00 +0000
Subject: [New-bugs-announce] [issue6033] LOOKUP_METHOD and CALL_METHOD
	optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This is an optimization ported from PyPy. [1] It tries to prevent bound
methods from being created by using the stack as a cache. I couldn't
apply this to builtin methods because those use a method-wrapper
descriptor. The results were not very impressive. However, I'm attaching
the patch to see if anyone else wants to look at it.

[1]
http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html#id1


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other 
 diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:   342ms   340ms   +0.6%   378ms   361ms
  +4.7%
           BuiltinMethodLookup:   315ms   308ms   +2.3%   333ms   319ms
  +4.5%
                 CompareFloats:   250ms   251ms   -0.3%   257ms   258ms
  -0.7%
         CompareFloatsIntegers:   266ms   265ms   +0.4%   273ms   273ms
  -0.2%
               CompareIntegers:   233ms   232ms   +0.4%   238ms   238ms
  -0.2%
        CompareInternedStrings:   279ms   275ms   +1.3%   285ms   284ms
  +0.3%
                  CompareLongs:   225ms   223ms   +1.1%   231ms   229ms
  +0.8%
                CompareStrings:   238ms   235ms   +1.3%   244ms   243ms
  +0.6%
                CompareUnicode:   243ms   246ms   -0.9%   252ms   252ms
  -0.1%
    ComplexPythonFunctionCalls:   307ms   301ms   +2.0%   315ms   309ms
  +1.8%
                 ConcatStrings:   372ms   366ms   +1.6%   376ms   385ms
  -2.1%
                 ConcatUnicode:   260ms   259ms   +0.4%   266ms   269ms
  -0.9%
               CreateInstances:   351ms   336ms   +4.7%   365ms   346ms
  +5.5%
            CreateNewInstances:   265ms   256ms   +3.6%   281ms   264ms
  +6.5%
       CreateStringsWithConcat:   290ms   289ms   +0.1%   304ms   301ms
  +1.2%
       CreateUnicodeWithConcat:   220ms   219ms   +0.8%   227ms   223ms
  +1.8%
                  DictCreation:   201ms   200ms   +0.4%   204ms   206ms
  -1.0%
             DictWithFloatKeys:   400ms   418ms   -4.4%   410ms   424ms
  -3.4%
           DictWithIntegerKeys:   298ms   294ms   +1.2%   306ms   304ms
  +0.6%
            DictWithStringKeys:   260ms   264ms   -1.5%   270ms   275ms
  -2.1%
                      ForLoops:   224ms   223ms   +0.2%   232ms   232ms
  +0.2%
                    IfThenElse:   160ms   160ms   +0.0%   168ms   182ms
  -8.0%
                   ListSlicing:   293ms   292ms   +0.5%   302ms   306ms
  -1.2%
                NestedForLoops:   301ms   300ms   +0.2%   305ms   308ms
  -0.8%
      NestedListComprehensions:   323ms   328ms   -1.7%   331ms   335ms
  -1.3%
          NormalClassAttribute:   313ms   314ms   -0.1%   323ms   330ms
  -2.1%
       NormalInstanceAttribute:   284ms   283ms   +0.4%   289ms   288ms
  +0.4%
           PythonFunctionCalls:   259ms   278ms   -6.7%   274ms   289ms
  -5.3%
             PythonMethodCalls:   358ms   357ms   +0.3%   371ms   365ms
  +1.6%
                     Recursion:   389ms   398ms   -2.1%   395ms   407ms
  -2.9%
                  SecondImport:   335ms   319ms   +5.2%   346ms   380ms
  -8.9%
           SecondPackageImport:   338ms   326ms   +3.6%   350ms   337ms
  +4.0%
         SecondSubmoduleImport:   413ms   403ms   +2.5%   426ms   411ms
  +3.6%
       SimpleComplexArithmetic:   341ms   345ms   -1.2%   351ms   355ms
  -1.1%
        SimpleDictManipulation:   288ms   298ms   -3.7%   293ms   303ms
  -3.1%
         SimpleFloatArithmetic:   272ms   275ms   -1.1%   279ms   286ms
  -2.7%
      SimpleIntFloatArithmetic:   211ms   204ms   +3.3%   216ms   215ms
  +0.5%
       SimpleIntegerArithmetic:   207ms   203ms   +1.7%   214ms   213ms
  +0.5%
      SimpleListComprehensions:   275ms   273ms   +0.6%   281ms   281ms
  -0.1%
        SimpleListManipulation:   224ms   229ms   -2.5%   234ms   241ms
  -2.9%
          SimpleLongArithmetic:   252ms   253ms   -0.6%   263ms   266ms
  -1.0%
                    SmallLists:   290ms   301ms   -3.8%   299ms   311ms
  -3.9%
                   SmallTuples:   254ms   253ms   +0.3%   261ms   266ms
  -1.9%
         SpecialClassAttribute:   311ms   309ms   +0.7%   320ms   321ms
  -0.2%
      SpecialInstanceAttribute:   358ms   358ms   +0.1%   370ms   371ms
  -0.4%
                StringMappings:   817ms   833ms   -1.9%   823ms   852ms
  -3.4%
              StringPredicates:   488ms   538ms   -9.2%   495ms   547ms
  -9.4%
                 StringSlicing:   295ms   296ms   -0.2%   306ms   323ms
  -5.5%
                     TryExcept:   282ms   280ms   +1.0%   291ms   288ms
  +1.0%
                    TryFinally:   290ms   255ms  +14.1%   300ms   263ms
 +14.1%
                TryRaiseExcept:   261ms   256ms   +1.7%   271ms   263ms
  +3.1%
                  TupleSlicing:   281ms   270ms   +4.3%   289ms   277ms
  +4.3%
               UnicodeMappings:   329ms   337ms   -2.4%   337ms   348ms
  -3.0%
             UnicodePredicates:   295ms   329ms  -10.4%   303ms   338ms
 -10.5%
             UnicodeProperties:   272ms   307ms  -11.4%   284ms   313ms
  -9.3%
                UnicodeSlicing:   258ms   261ms   -1.2%   266ms   275ms
  -3.2%
                   WithFinally:   384ms   398ms   -3.6%   394ms   408ms
  -3.5%
               WithRaiseExcept:   320ms   294ms   +8.9%   336ms   304ms
 +10.6%
-------------------------------------------------------------------------------

----------
components: Interpreter Core
files: call_method.patch
keywords: patch
messages: 87850
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: LOOKUP_METHOD and CALL_METHOD optimization
type: performance
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13992/call_method.patch

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

From report at bugs.python.org  Sat May 16 05:18:08 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 May 2009 03:18:08 +0000
Subject: [New-bugs-announce] [issue6034] Fix object.__reversed__ doc
In-Reply-To: <1242443888.15.0.235862846371.issue6034@psf.upfronthosting.co.za>
Message-ID: <1242443888.15.0.235862846371.issue6034@psf.upfronthosting.co.za>


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

3.3.5. Emulating container types
object.__reversed__(self)
says in 3.0 and 3.1 and I assume in 2.x:
"Objects should normally only provide __reversed__() if they do not
support the sequence protocol and an efficient implementation of reverse
iteration is possible."

The builtin sequences violate this because because they do support the
sequence and have __ reversed__ methods anyway.  And iterables that do
not support that protocol obviously *must* provide a method to be
reverse iterable.

I believe the point is that it is hard for Python code to beat the
C-coded version of the obvious

def __reversed__(self):
   for i in reversed(range(self.__len__)):
      yield self.__getitem__(i)

So I think the entry should say: "Objects that support the sequence
protocol should only provide __reversed__ if they can provide an
implementation that is more efficient than the one provided by
reversed()." possibly followed by "Objects that do not supposrt the
sequence protocol must provide __reversed__ to be reverse iterable."

----------
assignee: georg.brandl
components: Documentation
messages: 87852
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Fix object.__reversed__ doc
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May 16 10:58:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:58:52 +0000
Subject: [New-bugs-announce] [issue6035] test_poplib Bus error with gcc-4.4
	on OS X
In-Reply-To: <1242464332.58.0.076905856989.issue6035@psf.upfronthosting.co.za>
Message-ID: <1242464332.58.0.076905856989.issue6035@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

After building the py3k branch (r72674) with GCC 4.4 on OS X 10.5.7/x86
using:

CC=gcc-mp-4.4 ./configure --with-pydebug && make

test_poplib.py is crashing with a Bus error:

Macintosh-4:py3k dickinsm$ ./python.exe Lib/test/test_poplib.py
test_dele (__main__.TestPOP3Class) ... ok
test_exceptions (__main__.TestPOP3Class) ... ok
test_getwelcome (__main__.TestPOP3Class) ... ok
test_list (__main__.TestPOP3Class) ... ok
test_noop (__main__.TestPOP3Class) ... ok
test_pass_ (__main__.TestPOP3Class) ... ok
test_retr (__main__.TestPOP3Class) ... ok
test_rpop (__main__.TestPOP3Class) ... ok
test_stat (__main__.TestPOP3Class) ... ok
test_top (__main__.TestPOP3Class) ... ok
test_uidl (__main__.TestPOP3Class) ... ok
test_user (__main__.TestPOP3Class) ... ok
testTimeoutDefault (__main__.TestTimeouts) ... ok
testTimeoutNone (__main__.TestTimeouts) ... ok
testTimeoutValue (__main__.TestTimeouts) ... ok
test__all__ (__main__.TestPOP3_SSLClass) ... Bus error (core dumped)

gdb backtrace attached.

Setting priority to release blocker until we figure out that this isn't 
Python's fault.

----------
components: Extension Modules
files: poplib_backtrace.txt
messages: 87866
nosy: marketdickinson
priority: release blocker
severity: normal
status: open
title: test_poplib Bus error with gcc-4.4 on OS X
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file13994/poplib_backtrace.txt

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

From report at bugs.python.org  Sat May 16 11:20:58 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sat, 16 May 2009 09:20:58 +0000
Subject: [New-bugs-announce] [issue6036] test_posixpath.py
In-Reply-To: <1242465658.7.0.601350758359.issue6036@psf.upfronthosting.co.za>
Message-ID: <1242465658.7.0.601350758359.issue6036@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister <phihag at phihag.de>:

At line 300 (version 72674) there is the following interesting construction:

if hasattr(os, "symlink"):
     if hasattr(os, "symlink"):
          (...)
     (...)

hasattr is idempotent.

Additionally, test_posixpath.py is missing the shebang and the
svn:executable property.

----------
components: Tests
files: test_posixpath-cleanup.diff
keywords: patch
messages: 87871
nosy: phihag
severity: normal
status: open
title: test_posixpath.py
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13995/test_posixpath-cleanup.diff

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

From report at bugs.python.org  Sat May 16 13:05:54 2009
From: report at bugs.python.org (Cournapeau David)
Date: Sat, 16 May 2009 11:05:54 +0000
Subject: [New-bugs-announce] [issue6039] cygwin compilers should not check
	compiler versions
In-Reply-To: <1242471954.24.0.755904874213.issue6039@psf.upfronthosting.co.za>
Message-ID: <1242471954.24.0.755904874213.issue6039@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

cygwin compiler modules in distutils check versions of the toolchain,
and break is the version is not a released one.

I can't see the rationale for such a behavior, and it is particularly
annoying since it cannot be bypassed AFAIK. As it is the only toolchain
to use those version checks, I suggest to just remove them. This affects
every python version from 2.4 to 2.6, and possibly the 3.* versions as well.

----------
assignee: tarek
components: Distutils
messages: 87876
nosy: cdavid, tarek
severity: normal
status: open
title: cygwin compilers should not check compiler versions

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

From report at bugs.python.org  Sat May 16 13:08:26 2009
From: report at bugs.python.org (Cournapeau David)
Date: Sat, 16 May 2009 11:08:26 +0000
Subject: [New-bugs-announce] [issue6040] bdist_msi does not deal with
	pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

If bdist_msi is used on a package which has a non released version
(defined from StrictVersion), it refuses to build the package. The code
for the bdist_msi mentions that pre-release is not supported. Knowing
nothing about msi, I don't know what shall be done for it to work.

----------
messages: 87877
nosy: cdavid
severity: normal
status: open
title: bdist_msi does not deal with pre-release version
versions: Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat May 16 22:17:02 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 16 May 2009 20:17:02 +0000
Subject: [New-bugs-announce] [issue6042] Document and slightly simplify
	lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

lnotab-based tracing is very complicated and isn't documented very well.
There were at least 3 comment blocks purporting to document co_lnotab,
and none did a very good job. This patch unifies them into
Objects/lnotab_notes.txt which tries to completely capture the current
state of affairs.  I'm posting this here so that people can check that I
got it right. Thanks!

I also discovered that we've attached 2 layers of patches to the basic
tracing scheme. The first layer avoids jumping to instructions that
don't start a line, to avoid problems in if statements and while loops.
The second layer discovered that jumps backward do need to trace at
instructions that don't start a line, so it added extra lnotab entries
for 'while' and 'for' loops, and added a special case for backward jumps
within the same line. I replaced these patches by treating forward and
backward jumps differently.

I could simplify this slightly more by changing PyCode_CheckLineNumber.
 It doesn't appear to be used outside of the core, but since it doesn't
start with an _, I want to double-check that changing its interface is ok.

----------
components: Interpreter Core
files: lnotab.patch
keywords: needs review, patch
messages: 87919
nosy: jyasskin
severity: normal
stage: patch review
status: open
title: Document and slightly simplify lnotab tracing
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file13996/lnotab.patch

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

From report at bugs.python.org  Sun May 17 01:50:02 2009
From: report at bugs.python.org (Fred Bayer)
Date: Sat, 16 May 2009 23:50:02 +0000
Subject: [New-bugs-announce] [issue6043] HTMLParseError derivation
In-Reply-To: <1242517802.47.0.808968818979.issue6043@psf.upfronthosting.co.za>
Message-ID: <1242517802.47.0.808968818979.issue6043@psf.upfronthosting.co.za>


New submission from Fred Bayer <python at bayerf.de>:

Acoording to documentation, only a few exceptions should inherit
directly from Exception, most should inherit from StandardError.
However, HTMLParser.HTMLParseError doesn't conform:

isinstance(HTMLParser.HTMLParseError("foo"),StandardError) --> False

----------
components: Library (Lib)
messages: 87944
nosy: bayerf
severity: normal
status: open
title: HTMLParseError derivation
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sun May 17 05:18:01 2009
From: report at bugs.python.org (aletornw)
Date: Sun, 17 May 2009 03:18:01 +0000
Subject: [New-bugs-announce] [issue6044] Exception message in int() when
	trying to convert a	complex
In-Reply-To: <1242530281.91.0.594007385036.issue6044@psf.upfronthosting.co.za>
Message-ID: <1242530281.91.0.594007385036.issue6044@psf.upfronthosting.co.za>


New submission from aletornw <aletornw.spam at gmail.com>:

Hi, I noticed that when trying to convert with the int() function a
complex number the exception error says "use int(abs(z))". I think that
insted it should say "use int(z.real)" because if I want to convert
1j**2 to int using the abs method, the result is 1 positive, when it
should be -1. With my method it works fine.

----------
messages: 87955
nosy: aletornw
severity: normal
status: open
title: Exception message in int() when trying to convert a complex
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May 17 10:46:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:46:29 +0000
Subject: [New-bugs-announce] [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

All the dbm.* modules currently have different interfaces, and different
levels of supporting the Python3-style dictionary interface -- while the
docs claim they all have (most of) the dict interface.

For example, both dbm.gnu and dbm.ndbm only have keys() methods, and
they return a list.  Etc. for other dict-style methods.

So, either we remove the claim that they have a dict-style interface
beyond __*item__() and keys(), or we do something about it.

----------
components: Library (Lib)
messages: 87968
nosy: georg.brandl
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Fix dbm interfaces
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun May 17 10:50:07 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 08:50:07 +0000
Subject: [New-bugs-announce] [issue6046] test_distutils.py fails on
	VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>


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

test_disutils(test_get_outputs) fails on VC6. I cannot know if this
happens on VC9 too because buildbot is down. :-(

/////////////////////////////////////////////////////////////

test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... foo.c
   ??????
c:\docume~1\whiter~1\locals~1\temp\tmpzdhkyv\tempt\docume~1\whiter~1\l
ocals~1\temp\tmpkhvw2m\foo.lib ?????????
c:\docume~1\whiter~1\locals~1\temp\tmp
zdhkyv\tempt\docume~1\whiter~1\locals~1\temp\tmpkhvw2m\foo.exp ????
CVPACK : ??????? CK1003: ????
c:\docume~1\whiter~1\locals~1\temp\tmpb4w8fe\f
oo.exe ???????????
LINK : warning LNK4027: CVPACK error

/////////////////////////////////////////////////////////////

I looked into the directory "tmpkhvw2m" before it would be deleted, but
I could not find "foo.exe". There was only "foo".

----------
assignee: tarek
components: Distutils
messages: 87970
nosy: ocean-city, tarek
severity: normal
status: open
title: test_distutils.py fails on VC6(Windows)
versions: Python 2.7

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

From report at bugs.python.org  Sun May 17 12:22:36 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 May 2009 10:22:36 +0000
Subject: [New-bugs-announce] [issue6047] "install" target in python 3.x
	makefile should be	"fullinstall"
In-Reply-To: <1242555756.73.0.560342070509.issue6047@psf.upfronthosting.co.za>
Message-ID: <1242555756.73.0.560342070509.issue6047@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The default "install" target in the toplevel makefile for python 3.x 
behaves like the "altinstall" target in python 2.x. This behaviour was 
choosen to avoid conflicts between python 3.x and python 2.x 
installations.

IMO this is no longer needed, "make fullinstall" can coexist nicely with 
Python 2.x because the binaries that get installed for Python 3.x are 
named differently than those in Python 2.x.  Furthermore the 
"fullinstall" target is what most users will actually want to use: that 
install the 'unversioned' filenames.

I therefore propose to renamed the "install" target in Python 3.x to 
"altinstall" and to rename the "fullinstall" target to "install".

----------
assignee: benjamin.peterson
messages: 87980
nosy: benjamin.peterson, ronaldoussoren
severity: normal
status: open
title: "install" target in python 3.x makefile should be "fullinstall"
type: behavior
versions: Python 3.1

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

From martin at v.loewis.de  Sun May 17 13:05:31 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 17 May 2009 13:05:31 +0200
Subject: [New-bugs-announce] [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
References: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <4A0FEF7B.9060301@v.loewis.de>


> So, either we remove the claim that they have a dict-style interface
> beyond __*item__() and keys(), or we do something about it.

I disagree that this is release-critical. I think it is desirable to
say that the dbm modules support most of a dict-style interface,
and I also think that it is factually correct to claim that they
currently do.

The problem with the current documentation is that it apparently stopped
documenting the "dict-style interface", in the sense

http://www.python.org/doc/2.5/lib/typesmapping.html

did. Instead, the documentation now only documents the dict type itself.
If a dict-style interface was specified, one would have to specify
whether returning views from keys/values/items is part of the dict-style
interface or not.

From report at bugs.python.org  Sun May 17 20:48:56 2009
From: report at bugs.python.org (Erik Bernoth)
Date: Sun, 17 May 2009 18:48:56 +0000
Subject: [New-bugs-announce] [issue6049] str.strip() and " behaviour
	expected?
In-Reply-To: <1242586136.29.0.143891828835.issue6049@psf.upfronthosting.co.za>
Message-ID: <1242586136.29.0.143891828835.issue6049@psf.upfronthosting.co.za>


New submission from Erik Bernoth <sholvar at gmx.net>:

Hey guys,

is the following behaviour expected? I don't really think so...

$ python
Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>> 
>>> 
>>> s = ' "Peter"'
>>> s
' "Peter"'
>>> s.strip()
'"Peter"'
>>> s.strip('"')
' "Peter'
>>> s.strip('\"')
' "Peter'
>>> s.strip('\"\"')
' "Peter'
>>> 
>>> 
>>> 
>>> s.strip()
'"Peter"'
>>> s.strip().strip('"')
'Peter'
>>> s.strip('"').strip()
'"Peter'

----------
components: Library (Lib), Macintosh
messages: 87999
nosy: sholvar
severity: normal
status: open
title: str.strip() and " behaviour expected?
versions: Python 3.0

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

From report at bugs.python.org  Mon May 18 07:01:44 2009
From: report at bugs.python.org (Joe Amenta)
Date: Mon, 18 May 2009 05:01:44 +0000
Subject: [New-bugs-announce] [issue6050] zipfile: Extracting a directory
	that already exists	generates an OSError
In-Reply-To: <1242622904.12.0.492765760798.issue6050@psf.upfronthosting.co.za>
Message-ID: <1242622904.12.0.492765760798.issue6050@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

zipfile.ZipFile.extract() fails if targetpath is a directory that
already exists.

Bug revealed itself on Ubuntu, using extractall().

Happened on the latest 3.1 and 2.7.

Attached a patch that I think will fix this issue.

----------
components: Library (Lib)
files: zipdiff.diff
keywords: patch
messages: 88014
nosy: joe.amenta
severity: normal
status: open
title: zipfile: Extracting a directory that already exists generates an OSError
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14005/zipdiff.diff

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

From report at bugs.python.org  Mon May 18 11:13:52 2009
From: report at bugs.python.org (Thomas Guettler)
Date: Mon, 18 May 2009 09:13:52 +0000
Subject: [New-bugs-announce] [issue6051] smtplib docs should link to email
	module examples
In-Reply-To: <1242638032.14.0.154359322708.issue6051@psf.upfronthosting.co.za>
Message-ID: <1242638032.14.0.154359322708.issue6051@psf.upfronthosting.co.za>


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

On "smtplib example":
http://docs.python.org/library/smtplib.html#smtp-example
should be a link to:
http://docs.python.org/library/email-examples.html

I think the smtplib example is bad, since the email gets created with a
string. That's not solid. Using the email module is better.

----------
assignee: georg.brandl
components: Documentation
messages: 88020
nosy: georg.brandl, guettli
severity: normal
status: open
title: smtplib docs should link to email module examples
type: feature request

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

From report at bugs.python.org  Mon May 18 12:29:01 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Mon, 18 May 2009 10:29:01 +0000
Subject: [New-bugs-announce] [issue6052] for-loop doesn't work with -c
In-Reply-To: <1242642541.14.0.852784948983.issue6052@psf.upfronthosting.co.za>
Message-ID: <1242642541.14.0.852784948983.issue6052@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

I found this problem:

$ python3 -c 'import sys; for line in sys.stdout: pass'
  File "<string>", line 1
    import sys; for line in sys.stdout: pass
                  ^
SyntaxError: invalid syntax

Without import-statement this work great. Also code 'import sys; pass' 
works too.

----------
components: Interpreter Core
messages: 88024
nosy: exe
severity: normal
status: open
title: for-loop doesn't work with -c
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon May 18 13:07:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 May 2009 11:07:51 +0000
Subject: [New-bugs-announce] [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>


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

I found two distutils error on windows.

1. If the implementation of ensure_relative is correct, test should be
fixed like attached patch.

2. I got tar error. This happens because tar command I'm using cannot
recognize path with drive letter. For example, "tar -cf r:/foo ." fails
with error. I'm using http://gnuwin32.sourceforge.net/packages/gtar.htm

E:\python-dev\trunk\Lib\distutils\tests>py test_archive_util.py
..tar: Cannot open
c:\docume~1\whiter~1\locals~1\temp\tmprd9lcc\archive.tar: Fun
ction not implemented
tar: Error is not recoverable: exiting now
E.
======================================================================
ERROR: test_make_tarball (__main__.ArchiveUtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_archive_util.py", line 35, in test_make_tarball
    make_tarball(base_name, '.')
  File "e:\python-dev\trunk\lib\distutils\archive_util.py", line 47, in
make_tar
ball
    spawn(cmd, dry_run=dry_run)
  File "e:\python-dev\trunk\lib\distutils\spawn.py", line 37, in spawn
    _spawn_nt(cmd, search_path, dry_run=dry_run)
  File "e:\python-dev\trunk\lib\distutils\spawn.py", line 86, in _spawn_nt
    "command '%s' failed with exit status %d" % (cmd[0], rc)
DistutilsExecError: command 'tar' failed with exit status 2

----------------------------------------------------------------------
Ran 4 tests in 0.591s

FAILED (errors=1)
[32258 refs]

----------
assignee: tarek
components: Distutils
messages: 88025
nosy: ocean-city, tarek
severity: normal
status: open
title: distutils error on windows
versions: Python 2.7

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

From report at bugs.python.org  Mon May 18 18:19:57 2009
From: report at bugs.python.org (mkv)
Date: Mon, 18 May 2009 16:19:57 +0000
Subject: [New-bugs-announce] [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>


New submission from mkv <mvirkkil at cc.hut.fi>:

When creating tar archives using the tarfile module, requested arc names
are not respected. 

It is currently impossible to create a tar which when listing contents
would give:
$tar tvf test.tar
./
./control
./prerm
./postinst

The actual result will be
$tar tvf test.tar
./
control
prerm
postinst

This is caused by TarInfo's tobuf method calling normpath() on all file
names, even when the user has explicitly specified a certain name.

----------
components: Library (Lib)
messages: 88033
nosy: mkv
severity: normal
status: open
title: tarfile normalizes arcname
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May 18 18:52:27 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 18 May 2009 16:52:27 +0000
Subject: [New-bugs-announce] [issue6055] References to "pysqlite" in
	documentation of sqlite3	should be changed.
In-Reply-To: <1242665547.74.0.526289089631.issue6055@psf.upfronthosting.co.za>
Message-ID: <1242665547.74.0.526289089631.issue6055@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Why are there references to "pysqlite" in the documentation and examples
for the sqlite3 module. Was sqlite3 derived from the earlier pysqlite
module? Seems to me that all the references to "pysqlite" should read
"sqlite3", except maybe in a reworded attribution to the developer.

----------
assignee: georg.brandl
components: Documentation
messages: 88037
nosy: MLModel, georg.brandl
severity: normal
status: open
title: References to "pysqlite" in documentation of sqlite3 should be changed.
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon May 18 19:49:04 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 18 May 2009 17:49:04 +0000
Subject: [New-bugs-announce] [issue6056] socket.setdefaulttimeout affecting
	multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

Terminal 1:
Python 2.6.1 (r261:67515, Apr  2 2009, 18:25:55)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing.managers import SyncManager
>>> manager = SyncManager(authkey="mykey")
>>> manager.start()
>>> queue = manager.Queue()
>>> import pickle
>>> pickle.dump(queue, open("myqueue.pkl", "w"))
>>>

Terminal 2:
Python 2.6.1 (r261:67515, Apr  2 2009, 18:25:55)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.setdefaulttimeout(30)
>>> import multiprocessing, pickle
>>> multiprocessing.current_process().authkey = "mykey"
>>> queue = pickle.load(open("myqueue.pkl"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "python2.6/pickle.py", line 1370, in load
    return Unpickler(file).load()
  File "python2.6/pickle.py", line 858, in load
    dispatch[key](self)
  File "python2.6/pickle.py", line 1133, in load_reduce
    value = func(*args)
  File "python2.6/multiprocessing/managers.py", line 845, in RebuildProxy
    return func(token, serializer, incref=incref, **kwds)
  File "python2.6/multiprocessing/managers.py", line 894, in AutoProxy
    incref=incref)
  File "python2.6/multiprocessing/managers.py", line 700, in __init__
    self._incref()
  File "python2.6/multiprocessing/managers.py", line 749, in _incref
    conn = self._Client(self._token.address, authkey=self._authkey)
  File "python2.6/multiprocessing/connection.py", line 140, in Client
    answer_challenge(c, authkey)
  File "python2.6/multiprocessing/connection.py", line 376, in
answer_challenge
    response = connection.recv_bytes(256)        # reject large message
IOError: [Errno 11] Resource temporarily unavailable
>>> 

This works as expected without socket.setdefaulttimeout(). However, the
timeout is useful since if the listening process on terminal 1 goes to
sleep, e.g. ^Z, it would avoid blocking.

I suspect the cause is similar to http://bugs.python.org/issue976613

----------
components: Library (Lib)
messages: 88040
nosy: ryles
severity: normal
status: open
title: socket.setdefaulttimeout affecting multiprocessing Manager
versions: Python 2.6

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

From report at bugs.python.org  Mon May 18 21:02:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 18 May 2009 19:02:26 +0000
Subject: [New-bugs-announce] [issue6057] sqlite3 error classes should be
	documented
In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za>
Message-ID: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I can't find any documentation of the exception classes defined in the
sqlite3 module. There are quite a few, and some inheritance. The
examples in the sqlite3 module documentation have a few exception
clauses, but the errors they catch are not explained.

I would expect every module that defines exception classes to document
them, including inheritance. For a module like sqlite3 it is
particularly important because it is just an interface to C code.
Expecting someone to figure out exception classes from a module's Python
code is one thing, but asking them to go into the C code, which they
might not even have, is another.

----------
assignee: georg.brandl
components: Documentation
messages: 88044
nosy: MLModel, georg.brandl
severity: normal
status: open
title: sqlite3 error classes should be documented
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From martin at v.loewis.de  Mon May 18 22:16:36 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 18 May 2009 22:16:36 +0200
Subject: [New-bugs-announce] [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
References: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <4A11C224.7010907@v.loewis.de>

> 2. I got tar error. This happens because tar command I'm using cannot
> recognize path with drive letter. For example, "tar -cf r:/foo ." fails
> with error. I'm using http://gnuwin32.sourceforge.net/packages/gtar.htm

I don't think this is a bug in distutils, but rather in the tar command
that you are using.

From report at bugs.python.org  Tue May 19 04:16:57 2009
From: report at bugs.python.org (Yu Yuwei)
Date: Tue, 19 May 2009 02:16:57 +0000
Subject: [New-bugs-announce] [issue6059] uuid.uuid4 cause segfault in emesene
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>


New submission from Yu Yuwei <acevery at gmail.com>:

I'm on Gentoo Linux with glibc-2.9_20081201-r2, python-2.6.2,
e2fsprogs-libs-1.41.3-r1
When Emesene send offline message to another msn user, it call uuid4()
in uuid module in python, which call get_random_fd()
in gen_uuid.c(e2fsprogs-libs).
After this, the program got signal SIGSEGV.

When I used gdb attach to the python process, I got these:
##########################
(gdb) c
Continuing.
[New Thread 0xb1c09b90 (LWP 6445)]
[Thread 0xb1c09b90 (LWP 6445) exited]
[New Thread 0xb1c09b90 (LWP 6446)]
[New Thread 0xb118cb90 (LWP 6447)]
[New Thread 0xb098bb90 (LWP 6448)]
[New Thread 0xb018ab90 (LWP 6449)]
[Thread 0xb018ab90 (LWP 6449) exited]
[Thread 0xb098bb90 (LWP 6448) exited]
[Thread 0xb1c09b90 (LWP 6446) exited]
[Thread 0xb118cb90 (LWP 6447) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d126c0 (LWP 6423)]
0xb6f0745e in get_random_fd () at gen_uuid.c:153
153 gen_uuid.c: No such file or directory.
in gen_uuid.c
################

(gdb) bt
#0 0xb6f0745e in get_random_fd () at gen_uuid.c:153
#1 0xb6f07509 in get_random_bytes (buf=0xbfe3fc70, nbytes=16)
at gen_uuid.c:172
#2 0xb6f086ee in uuid__generate_random (out=0x9f62fc8 "", num=0xbfe3fcb4)
at gen_uuid.c:591
#3 0xb6f08780 in uuid_generate_random (out=0x9f62fc8 "") at
gen_uuid.c:607
#4 0xb666e3db in ffi_call_SYSV ()
from /usr/lib/python2.6/lib-dynload/_ctypes.so
#5 0xb666e159 in ffi_call () from
/usr/lib/python2.6/lib-dynload/_ctypes.so
#6 0xb6668ebb in _CallProc () from
/usr/lib/python2.6/lib-dynload/_ctypes.so
#7 0xb66620eb in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so
#8 0xb6f08755 in uuid__generate_random (out=0x9f4950c "\005",
num=0xa7fdb2c)
at gen_uuid.c:600
#9 0xb7ed0dba in PyObject_Call () from /usr/lib/libpython2.6.so.1.0
#10 0xb7f679b0 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0
#11 0xb7f6ae49 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0
#12 0xb7f6ae49 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0
#13 0xb7f6b72e in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0
#14 0xb7efb774 in ?? () from /usr/lib/libpython2.6.so.1.0
#15 0x0a23ce30 in ?? ()
#16 0x0a14d02c in ?? ()
#17 0x00000000 in ?? ()
###########

the line 153 in get_uuid.c is
" jrand_seed[0] = getpid() ^ (tv.tv_sec & 0xFFFF);"
so in gdb I type:
(gdb) p jrand_seed[0]
Cannot access memory at address 0x30
#######

So this cause the segfault. But I don't know why.
May be related to the THREAD_LOCAL keywords :

#if defined(__linux__) && defined(__NR_gettid) && defined(HAVE_JRAND48)
#define DO_JRAND_MIX
THREAD_LOCAL unsigned short jrand_seed[3];
#endif

I try emesene with another gentoo box with same glibc and same
e2fsprogs-libs, but with python-2.5, everything is fine.

So this seems a bug in python-2.6.

----------
messages: 88061
nosy: acevery
severity: normal
status: open
title: uuid.uuid4 cause segfault in emesene
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue May 19 07:52:24 2009
From: report at bugs.python.org (soundmurderer)
Date: Tue, 19 May 2009 05:52:24 +0000
Subject: [New-bugs-announce] [issue6060] PYTHONHOME should be more flexible
	(and controllable by	--libdir)
In-Reply-To: <1242712344.32.0.862299052402.issue6060@psf.upfronthosting.co.za>
Message-ID: <1242712344.32.0.862299052402.issue6060@psf.upfronthosting.co.za>


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

The PYTHONHOME variable does not allow complete control over making a
Python installation find its own libs because "lib/pythonX.Y" gets
appended to it, see:
    http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME

For example, let's say my Python installation is here:
    /home/soundmurderer/lib/x86_64/python2.6

I cannot set PYTHONHOME to point to this, because my path does not end
in "lib/pythonX.Y".  Of course, you could say that I should just move
the Python libs, but it may create inconsistencies on how stuff is
organized on some systems.  PYTHONHOME should point to the Python
installation root, period.  Please give the admin complete control.

Also, the --libdir flag to ./configure should work and set PYTHONHOME
correctly.  The fact that it does nothing has its own ticket, see:
    http://bugs.python.org/issue858809

It is, however, my humble opinion that fixing that other ticket properly
also necessitates fixing how PYTHONHOME works (because --libdir should
set the default PYTHONHOME during build/install), so they should really
be one issue.

Thanks!

----------
components: Build, Installation
messages: 88066
nosy: soundmurderer
severity: normal
status: open
title: PYTHONHOME should be more flexible (and controllable by --libdir)
type: feature request
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue May 19 08:43:03 2009
From: report at bugs.python.org (Thomas Reiter)
Date: Tue, 19 May 2009 06:43:03 +0000
Subject: [New-bugs-announce] [issue6061] time.clock(): overflow in programs
	that run for very long
In-Reply-To: <1242715383.27.0.654529899967.issue6061@psf.upfronthosting.co.za>
Message-ID: <1242715383.27.0.654529899967.issue6061@psf.upfronthosting.co.za>


New submission from Thomas Reiter <thomasr at nikhef.nl>:

On a 64-bit Linux machine the attached program generates the following
(shortened) output:

$ python bug.py
...
after 2145.49s: 
after 2145.82s: 
after 2146.14s: 
after 2146.47s: 
after 2146.80s: 
after 2147.13s: 
after 2147.45s: 
after -2147.19s: 
Here's your bug

---------------------------------------------
$ uname -a
Linux XXXX 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 06:45:03 EST 2008 x86_64
x86_64 x86_64 GNU/Linux

$ python -V
Python 2.6

----------
components: Library (Lib)
files: bug.py
messages: 88069
nosy: tom65536
severity: normal
status: open
title: time.clock(): overflow in programs that run for very long
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14015/bug.py

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

From report at bugs.python.org  Tue May 19 21:08:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:08:30 +0000
Subject: [New-bugs-announce] [issue6063] pydoc_data package is not installed
In-Reply-To: <1242760110.37.0.882405849685.issue6063@psf.upfronthosting.co.za>
Message-ID: <1242760110.37.0.882405849685.issue6063@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The package Lib/pydoc_data is not installed by Makefile.pre.in. Because 
of this "pydoc if" won't work.

The attached patch fixes this issue. I've applied this patch to the 
trunk (r72787) and py3k (r72788), and filed this issue because I'm not 
100% sure if this should be backported to 2.6 (because this fix causes 
additional python modules to be made available).

(Assigned to Georg Brandl because he committed the last changes to 
pydoc_data, and is the documentation guru)

----------
assignee: georg.brandl
files: pydoc_data.patch
keywords: 26backport, patch
messages: 88086
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: pydoc_data package is not installed
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14017/pydoc_data.patch

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

From report at bugs.python.org  Tue May 19 21:14:01 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 19 May 2009 19:14:01 +0000
Subject: [New-bugs-announce] [issue6064] Add "daemon" argument to
	threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

It would be nice if threading.Thread constructor will have a "daemon"
argument as well.

This way we'll be able to write
    Thread(target=some_function, daemon=1).start()

Instead of currently writing
    t = Thread(target=some_function)
    t.daemon = True
    t.start()

----------
components: Library (Lib)
messages: 88088
nosy: tebeka
severity: normal
status: open
title: Add "daemon" argument to threading.Thread constructor
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Tue May 19 23:51:45 2009
From: report at bugs.python.org (Tim Golden)
Date: Tue, 19 May 2009 21:51:45 +0000
Subject: [New-bugs-announce] [issue6065] bdist_msi.py failed assert when
	including extension	modules
In-Reply-To: <4A1329EC.3020307@timgolden.me.uk>
Message-ID: <4A1329EC.3020307@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

Attempting to build an MSI installer using bdist_msi fails
under Windows when the module contains extension modules.
The assert at line 197 fires as no target version has been
specified. The attached tentative patch makes sure a target
version is set to the current version which has the added
advantage that the installer does not offer all possible
versions which would be inappropriate for a binary extension.

Patch against r72306

----------
files: bdist_msi.patch
keywords: patch
messages: 88098
nosy: tim.golden
severity: normal
status: open
title: bdist_msi.py failed assert when including extension modules
Added file: http://bugs.python.org/file14019/bdist_msi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6065>
_______________________________________
-------------- next part --------------
Index: bdist_msi.py
===================================================================
--- bdist_msi.py	(revision 72507)
+++ bdist_msi.py	(working copy)
@@ -141,6 +141,8 @@
             bdist_base = self.get_finalized_command('bdist').bdist_base
             self.bdist_dir = os.path.join(bdist_base, 'msi')
         short_version = get_python_version()
+        if (not self.target_version) and self.distribution.has_ext_modules():
+          self.target_version = short_version
         if self.target_version:
             self.versions = [self.target_version]
             if not self.skip_build and self.distribution.has_ext_modules()\

From report at bugs.python.org  Wed May 20 03:31:13 2009
From: report at bugs.python.org (Collin Winter)
Date: Wed, 20 May 2009 01:31:13 +0000
Subject: [New-bugs-announce] [issue6066] POP_MARK was not in pickle protocol
	0
In-Reply-To: <1242783073.43.0.508281070334.issue6066@psf.upfronthosting.co.za>
Message-ID: <1242783073.43.0.508281070334.issue6066@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

Lib/pickletools.py incorrectly thinks POP_MARK was part of protocol 0;
POP_MARK was only added with the introduction of protocol 1 in r7753.
This mistake led me down a dead end while fixing another pickling issue.

Alexandre, can you double-check me on this? Feel free to bounce this
back if you don't have time.

I'll port this to py3k. I'm leaning toward a backport to 2.6; any
thoughts on that?

----------
components: Library (Lib)
files: pickletools.patch
keywords: easy, patch
messages: 88105
nosy: alexandre.vassalotti, collinwinter
priority: low
severity: normal
stage: patch review
status: open
title: POP_MARK was not in pickle protocol 0
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14020/pickletools.patch

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

From report at bugs.python.org  Wed May 20 11:01:06 2009
From: report at bugs.python.org (gast)
Date: Wed, 20 May 2009 09:01:06 +0000
Subject: [New-bugs-announce] [issue6067] make error
In-Reply-To: <1242810066.3.0.038429040919.issue6067@psf.upfronthosting.co.za>
Message-ID: <1242810066.3.0.038429040919.issue6067@psf.upfronthosting.co.za>


New submission from gast <gast83 at inbox.ru>:

please help my!

OS - AIX 5.3 64x
i have need to install Python 2.6

./configure --with-gcc

configure: WARNING: wchar.h: present but cannot be compiled
configure: WARNING: wchar.h:     check for missing prerequisite headers?
configure: WARNING: wchar.h: see the Autoconf documentation
configure: WARNING: wchar.h:     section "Present But Cannot Be 
Compiled"
configure: WARNING: wchar.h: proceeding with the preprocessor's result
configure: WARNING: wchar.h: in the future, the compiler will take 
precedence
configure: WARNING:     ## ---------------------------------------------
--- ##
configure: WARNING:     ## Report this to http://www.python.org/python-
bugs ##
configure: WARNING:     ## ---------------------------------------------
--- ##

 
make

In file included from Include/unicodeobject.h:120,
                 from Include/Python.h:85,
                 from ./Modules/python.c:3:
/opt/freeware/lib/gcc/powerpc-ibm-aix5.1.0.0/4.0.0/include/wchar.h:299: 
error: parse error before 'mbstate_t'
/opt/freeware/lib/gcc/powerpc-ibm-aix5.1.0.0/4.0.0/include/wchar.h:302: 
error: parse error before 'mbstate_t'
make: 1254-004 The error code from the last command is 1.

What can i do for correct it? please...

----------
components: Installation
messages: 88108
nosy: gast
severity: normal
status: open
title: make error
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed May 20 11:47:11 2009
From: report at bugs.python.org (higstar)
Date: Wed, 20 May 2009 09:47:11 +0000
Subject: [New-bugs-announce] [issue6068] c_ulonglong structure members
	appear read-only
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>


New submission from higstar <adrian at higstar.com>:

When defining a structure with members of ctype type c_ulonglong, some
members appear read only?

I created this test.py and appended the results below:
-----
import ctypes
import time

class all_ulong(ctypes.BigEndianStructure):
    _fields_    = [
                   ("Data0",   ctypes.c_ulong, 4),
                   ("Data1",   ctypes.c_ulong, 4),
                  ]
class all_ulonglong(ctypes.BigEndianStructure):
    _fields_    = [
                   ("Data0",   ctypes.c_ulonglong, 4),
                   ("Data1",   ctypes.c_ulonglong, 4),
                  ]

def inc_both_members(test):
    test.Data0 += 1
    test.Data1 += 1
def print_both_members(test):
    print("Data0 is %d, Data1 is %d for %s"%(test.Data0, test.Data1,
test.__class__.__name__))

tests = [all_ulong(), all_ulonglong()]
for test in tests:
    print_both_members(test)

Failed = False
while not Failed:
    for test in tests:
        inc_both_members(test)
        print_both_members(test)
    if not tests[0].Data0 == tests[1].Data0: 
        Failed = True
    if not tests[0].Data1 == tests[1].Data1: 
        Failed = True
-----
>c:\python25\python.exe test.py
Data0 is 0, Data1 is 0 for all_ulong
Data0 is 0, Data1 is 0 for all_ulonglong
Data0 is 1, Data1 is 1 for all_ulong
Data0 is 1, Data1 is 1 for all_ulonglong
Data0 is 2, Data1 is 2 for all_ulong
Data0 is 2, Data1 is 1 for all_ulonglong

>c:\python26\python.exe test.py
Data0 is 0, Data1 is 0 for all_ulong
Data0 is 0, Data1 is 0 for all_ulonglong
Data0 is 1, Data1 is 1 for all_ulong
Data0 is 1, Data1 is 1 for all_ulonglong
Data0 is 2, Data1 is 2 for all_ulong
Data0 is 2, Data1 is 1 for all_ulonglong

>c:\python30\python.exe test.py
Data0 is 0, Data1 is 0 for all_ulong
Data0 is 0, Data1 is 0 for all_ulonglong
Data0 is 1, Data1 is 1 for all_ulong
Data0 is 1, Data1 is 1 for all_ulonglong
Data0 is 2, Data1 is 2 for all_ulong
Data0 is 2, Data1 is 1 for all_ulonglong


As you can see the second member Data1, is not incrementing correctly.

I found this issue because I started using c_ulonglong types for all
members so that when casting a byte stream to one of these ctype
structures, there are no incorrect values when casting to a member
crossing byte/word/long boundaries.

----------
assignee: theller
components: ctypes
messages: 88110
nosy: higstar, theller
severity: normal
status: open
title: c_ulonglong structure members appear read-only
type: compile error
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed May 20 12:32:28 2009
From: report at bugs.python.org (higstar)
Date: Wed, 20 May 2009 10:32:28 +0000
Subject: [New-bugs-announce] [issue6069] casting error from ctypes array to
	structure
In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za>
Message-ID: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za>


New submission from higstar <adrian at higstar.com>:

Structure fails to correctly cast from a 2 byte bitfield.

>From my very limited investigation, is looks like when using a member
type of less than the total size of the structure (or at least the size
of any byte boundaries) the casting is not done correctly?

I created this test.py and appended the results below:

---
import ctypes
import time

class closest_fit(ctypes.BigEndianStructure):
#    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_ubyte, 7),
                   ("Data1",   ctypes.c_ubyte, 8),
                   ]

class all_ulong(ctypes.BigEndianStructure):
#    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_ulonglong, 7),
                   ("Data1",   ctypes.c_ulonglong, 8),
                  ]

def castbytes(type):
    buffer = (ctypes.c_byte * 2)()
    buffer[0] = 0x55
    buffer[1] = 0x55
    return ctypes.cast(ctypes.pointer(buffer),
ctypes.POINTER(type)).contents

def print_members(test):
    print("Data0 is 0x%X, Data1 is 0x%X for %s"%(test.Data0, test.Data1,
test.__class__.__name__))

test_classes = [ closest_fit, all_ulonglong]

Failed = False
tests = [castbytes(type) for type in test_classes]
for test in tests:
    print_members(test)
    if not tests[0].Data0 == tests[1].Data0: 
        Failed = True
    if not tests[0].Data1 == tests[1].Data1: 
        Failed = True

if Failed:
    print("Failed")
else:
    print("Passed")
---

>c:\python25\python.exe test.py
Data0 is 0x2A, Data1 is 0x55 for closest_fit
Data0 is 0x2A, Data1 is 0xAA for all_ulonglong
Failed

>c:\python26\python.exe test.py
Data0 is 0x2A, Data1 is 0x55 for closest_fit
Data0 is 0x2A, Data1 is 0xAA for all_ulonglong
Failed

>c:\python30\python.exe test.py
Data0 is 0x2A, Data1 is 0x55 for closest_fit
Data0 is 0x2A, Data1 is 0xAA for all_ulonglong
Failed

As you can see the second member Data1, should be 0xAA, however when
using c_ubyte types for members the value is not offset by one bit.

As you can see using c_ulonglong for all members avoids this issue,
however this results in a read only structure (see Issue 6068).

I am using structures to cast CAN messages which are 8 bytes, with very
funky bit fields crossing all sorts of byte boundaries, so I essentially
expected that ctypes would provide a method for an arbitrary bit field
definition for use within python.  Hopefully this is just my bad ctypes
driving, or a simple fix.

----------
assignee: theller
components: ctypes
messages: 88111
nosy: higstar, theller
severity: normal
status: open
title: casting error from ctypes array to structure
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed May 20 12:58:49 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Wed, 20 May 2009 10:58:49 +0000
Subject: [New-bugs-announce] [issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode
	files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>


New submission from Oleg Broytmann <phd at phd.pp.ru>:

On compilation of .pyc/.pyo bytecode files on import Python 2.6 copies
Unix file access attributes (-rwx-) from the imported file. I'd think
it's ok except for executable (-x-) bit - bytecode files are not
directly executable. That is, for a module.py with attributes -rwxr-x---
I expect python2.6 -c 'import module' would produce module.pyc with
attributes -rw-r-----.

python compileall.py . saves compiled files without the executable bit;
it doesn't copy attributes - it just saves files and saving obeys umask.
python2.5 -c 'import module.py' doesn't copy the executable bit, it
obeys umask too. I consider this as a regression in 2.6. Please mask out
executable bits on bytecode files saving.

----------
components: Interpreter Core
messages: 88112
nosy: phd
severity: normal
status: open
title: Pyhon 2.6 makes .pyc/.pyo bytecode files executable
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May 20 19:17:15 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 20 May 2009 17:17:15 +0000
Subject: [New-bugs-announce] [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

It used to be possible to use hashlib with arrays; it no longer seems
possible.

exarkun at charm:~$ python -c '
import sys, hashlib, array
print sys.version_info
print hashlib.sha1(array.array("b", [1, 2, 3])).hexdigest()
'
(2, 5, 2, 'final', 0)
7037807198c22a7d2b0807371d763779a84fdfcf
exarkun at charm:~$ ~/Projects/python/trunk/python -c '
import sys, hashlib, array
print sys.version_info
print hashlib.sha1(array.array("b", [1, 2, 3])).hexdigest()
'
sys.version_info(major=2, minor=7, micro=0, releaselevel='alpha', serial=0)
Traceback (most recent call last):
  File "<string>", line 4, in <module>
TypeError: object supporting the buffer API required
exarkun at charm:~$

----------
components: Library (Lib)
messages: 88122
nosy: exarkun
severity: normal
status: open
title: no longer possible to hash arrays
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 20 19:56:34 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 20 May 2009 17:56:34 +0000
Subject: [New-bugs-announce] [issue6072] unittest.TestCase._result is very
	likely to collide (and	break) with application-defined
	TestCase attributes
In-Reply-To: <1242842194.25.0.855892294784.issue6072@psf.upfronthosting.co.za>
Message-ID: <1242842194.25.0.855892294784.issue6072@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

r72219 introduced an `_result? attribute to `TestCase?.  As `TestCase?
is designed specifically with the intent that applications should
subclass it -- and frequently -- I would suggest that the attribute be
given a name less likely to collide with a name chosen by application
code.  Given the huge quantity of `TestCase? subclasses, it will likely
be a great time saver to address the collision in CPython rather than in
each application.

----------
components: Library (Lib)
messages: 88124
nosy: exarkun
severity: normal
status: open
title: unittest.TestCase._result is very likely to collide (and break) with application-defined TestCase attributes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 20 22:42:30 2009
From: report at bugs.python.org (Eric Atienza)
Date: Wed, 20 May 2009 20:42:30 +0000
Subject: [New-bugs-announce] [issue6073] threading.Timer and gtk.main are
	not compatible
In-Reply-To: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>
Message-ID: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>


New submission from Eric Atienza <eric at ericaro.net>:

this simple code:
"
import gtk
from threading import Timer
from time import sleep

def p():
    print "p"

Timer(1, p).start()

#gtk.main()
sleep(10)
print "done"
does print "p" a second after it starts.
when I remove the comment of the gtk.main() line: the "p" is never printed.

It is very exposed, as Timer is a common tool to build a GUI therefore
with the gtk.main() loop active.

----------
components: Library (Lib)
messages: 88137
nosy: atienza
severity: normal
status: open
title: threading.Timer and gtk.main are not compatible
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 21 00:04:23 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Wed, 20 May 2009 22:04:23 +0000
Subject: [New-bugs-announce] [issue6074] .pyc files created readonly if .py
	file is readonly, python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>


New submission from Peter Simanyi <psimanyi at namcobandaigames.com>:

Some source code control tools, like Perforce, by default sync files readonly, and it's useful to 
leave them readonly so that you can mark files changed by making them writeable even if they're not 
checked out (e.g. working offline).

When python implicitly compiles a .py file that's readonly, it will create a .pyc file that's 
readonly. This would be fine, except that when the .py file changes, python *silently* refuses to 
overwrite a .pyc file that's readonly, even if the directory is completely writable by the user 
executing Python.

The attached script shows this behavior. Running "python -v" will produce the following line 
showing this:

  import b # from c:\Documents and Settings\psimanyi\tmp\b.py
  # can't create c:\Documents and Settings\psimanyi\tmp\b.pyc

And because I hoped this was a Windows-only problem, I tested on OSX (Leopard) and Ubuntu (9.10 
alpha): it occurs on all three platforms.

Thanks!

--------------------------------

I fixed showpycreadonly.sh after attaching it, so to be sure you have the current version, it 
follows:

rm -f [ab].py{,c}

echo 'import b' > a.py
echo 'print "b"' > b.py
ls -l b.py
python a.py
ls -l b.pyc
rm b.pyc
chmod -w b.py
python a.py
ls -l b.pyc
touch b.py
python -v a.py 2>&1 | grep b.py

----------
components: Interpreter Core
files: showpycreadonly.sh
messages: 88138
nosy: pdsimanyi
severity: normal
status: open
title: .pyc files created readonly if .py file is readonly, python won't overwrite
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14025/showpycreadonly.sh

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

From report at bugs.python.org  Thu May 21 00:25:24 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:25:24 +0000
Subject: [New-bugs-announce] [issue6075] Patch for IDLE/OS X to work with
	Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>


New submission from Kevin Walzer <wordtech at users.sourceforge.net>:

In version 8.6 of Tk (now in beta stage), Tk on OS X will be built on top 
of the Cocoa API, replacing the deprecated Carbon API. Tk-Cocoa implements 
some UI behaviors (help menu, application menu) differently than Tk-
Carbon. The attached files patch IDLE to detect whether Tk is built on top 
of Cocoa or Carbon, and implement the correct UI behavior.

----------
components: IDLE
files: EditorWindow.patch
keywords: patch
messages: 88139
nosy: wordtech
severity: normal
status: open
title: Patch for IDLE/OS X to work with Tk-Cocoa
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14026/EditorWindow.patch

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

From report at bugs.python.org  Thu May 21 00:54:10 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:54:10 +0000
Subject: [New-bugs-announce] [issue6076] Missing title for configDialog.py
In-Reply-To: <1242860050.65.0.436553744658.issue6076@psf.upfronthosting.co.za>
Message-ID: <1242860050.65.0.436553744658.issue6076@psf.upfronthosting.co.za>


New submission from Kevin Walzer <wordtech at users.sourceforge.net>:

The configDialog for IDLE in version 2.6.2 is missing a title in the 
window: this patch adds a "Preferences" title to the window.

----------
components: IDLE
files: configDialog.patch
keywords: patch
messages: 88143
nosy: wordtech
severity: normal
status: open
title: Missing title for configDialog.py
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14030/configDialog.patch

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

From report at bugs.python.org  Thu May 21 16:28:20 2009
From: report at bugs.python.org (Michael Zalokar)
Date: Thu, 21 May 2009 14:28:20 +0000
Subject: [New-bugs-announce] [issue6078] freeze.py doesn't work
In-Reply-To: <1242916100.37.0.236967212575.issue6078@psf.upfronthosting.co.za>
Message-ID: <1242916100.37.0.236967212575.issue6078@psf.upfronthosting.co.za>


New submission from Michael Zalokar <zalokar at fnal.gov>:

I've tried this with python 2.6.0, python 2.6.1 and python 2.6.2 all
with the same results.


bash-3.2$ cat hello.py
print "hello world"
bash-3.2$ python -V
Python 2.6.2
bash-3.2$ python $PYTHON_DIR/Python-2.6.2/Tools/freeze/freeze.py hello.py

  Name                      File
  ----                      ----
m BaseHTTPServer           
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/BaseHTTPServer.py
m FixTk                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-tk/FixTk.py
m SocketServer             
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/SocketServer.py
m StringIO                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/StringIO.py
m Tkconstants              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-tk/Tkconstants.py
m Tkinter                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-tk/Tkinter.py
m UserDict                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/UserDict.py
m __builtin__
m __future__               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/__future__.py
m __main__                  hello.py
m _abcoll                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/_abcoll.py
m _bisect                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_bisect.so
m _codecs
m _collections             
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_collections.so
m _ctypes                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_ctypes.so
m _functools               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_functools.so
m _heapq                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_heapq.so
m _locale                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_locale.so
m _random
m _socket
m _sre
m _ssl                     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/_ssl.so
m _struct
m _threading_local         
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/_threading_local.py
m _tkinter
m _warnings
m abc                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/abc.py
m array
m base64                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/base64.py
m bdb                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/bdb.py
m binascii                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/lib-dynload/binascii.so
m bisect                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/bisect.py
m cPickle
m cStringIO
m cmd                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/cmd.py
m codecs                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/codecs.py
m collections              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/collections.py
m copy                     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/copy.py
m copy_reg                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/copy_reg.py
P ctypes                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/__init__.py
m ctypes._endian           
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/_endian.py
P ctypes.macholib          
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/macholib/__init__.py
m ctypes.macholib.dyld     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/macholib/dyld.py
m ctypes.macholib.dylib    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/macholib/dylib.py
m ctypes.macholib.framework
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/macholib/framework.py
m ctypes.util              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ctypes/util.py
m difflib                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/difflib.py
m dis                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/dis.py
P distutils                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/__init__.py
m distutils.dep_util       
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/dep_util.py
m distutils.errors         
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/errors.py
m distutils.log            
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/log.py
m distutils.spawn          
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/spawn.py
m distutils.sysconfig      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/sysconfig.py
m distutils.text_file      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/text_file.py
m distutils.util           
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/distutils/util.py
m doctest                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/doctest.py
m dummy_thread             
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/dummy_thread.py
m dummy_threading          
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/dummy_threading.py
P email                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/__init__.py
m email._parseaddr         
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/_parseaddr.py
m email.base64mime         
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/base64mime.py
m email.charset            
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/charset.py
m email.encoders           
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/encoders.py
m email.errors             
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/errors.py
m email.feedparser         
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/feedparser.py
m email.message            
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/message.py
P email.mime               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/mime/__init__.py
m email.parser             
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/parser.py
m email.quoprimime         
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/quoprimime.py
m email.utils              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/email/utils.py
P encodings                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/encodings/__init__.py
m encodings.aliases        
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/encodings/aliases.py
m errno
m fcntl
m fnmatch                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/fnmatch.py
m formatter                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/formatter.py
m ftplib                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ftplib.py
m functools                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/functools.py
m gc
m genericpath              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/genericpath.py
m getopt                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/getopt.py
m getpass                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/getpass.py
m gettext                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/gettext.py
m glob                     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/glob.py
m heapq                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/heapq.py
m httplib                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/httplib.py
m imp
m inspect                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/inspect.py
m itertools
m keyword                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/keyword.py
m linecache                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/linecache.py
m locale                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/locale.py
m macurl2path              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/macurl2path.py
m marshal
m math
m mimetools                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/mimetools.py
m mimetypes                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/mimetypes.py
m ntpath                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ntpath.py
m nturl2path               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/nturl2path.py
m opcode                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/opcode.py
m operator
m optparse                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/optparse.py
m os                       
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/os.py
m os2emxpath               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/os2emxpath.py
m pdb                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/pdb.py
m pickle                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/pickle.py
m pkgutil                  
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/pkgutil.py
m posix
m posixpath                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/posixpath.py
m pprint                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/pprint.py
m pwd
m py_compile               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/py_compile.py
m pydoc                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/pydoc.py
m pydoc_topics             
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/pydoc_topics.py
m quopri                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/quopri.py
m random                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/random.py
m re                       
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/re.py
m readline
m repr                     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/repr.py
m rfc822                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/rfc822.py
m select
m shlex                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/shlex.py
m signal
m site                     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/site.py
m socket                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/socket.py
m sre_compile              
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/sre_compile.py
m sre_constants            
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/sre_constants.py
m sre_parse                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/sre_parse.py
m ssl                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/ssl.py
m stat                     
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/stat.py
m string                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/string.py
m strop
m struct                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/struct.py
m subprocess               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/subprocess.py
m sys
m tempfile                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/tempfile.py
m termios
m textwrap                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/textwrap.py
m thread
m threading                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/threading.py
m time
m token                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/token.py
m tokenize                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/tokenize.py
m traceback                
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/traceback.py
m tty                      
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/tty.py
m types                    
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/types.py
m unittest                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/unittest.py
m urllib                   
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/urllib.py
m urlparse                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/urlparse.py
m uu                       
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/uu.py
m warnings                 
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/warnings.py
m webbrowser               
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/webbrowser.py
m zipimport

Missing modules:
? EasyDialogs imported from getpass
? MacOS imported from distutils.sysconfig, py_compile
? SOCKS imported from ftplib
? _dummy_threading imported from dummy_threading
? _emx_link imported from os
? _subprocess imported from subprocess
? _winreg imported from urllib
? ce imported from os
? email.Generator imported from email.message
? email.Iterators imported from email.message
? ic imported from pydoc, webbrowser
? msvcrt imported from getpass, subprocess
? nt imported from ntpath, os
? org.python.core imported from copy, pickle
? os.path imported from os, pkgutil, shlex
? os2 imported from os
? riscos imported from os
? riscosenviron imported from os
? riscospath imported from os
? rourl2path imported from urllib
? sitecustomize imported from site
? usercustomize imported from site

freezing BaseHTTPServer ...
freezing FixTk ...
freezing SocketServer ...
freezing StringIO ...
freezing Tkconstants ...
freezing Tkinter ...
freezing UserDict ...
freezing __future__ ...
freezing __main__ ...
freezing _abcoll ...
freezing _threading_local ...
freezing abc ...
freezing base64 ...
freezing bdb ...
freezing bisect ...
freezing cmd ...
freezing codecs ...
freezing collections ...
freezing copy ...
freezing copy_reg ...
freezing ctypes ...
freezing ctypes._endian ...
freezing ctypes.macholib ...
freezing ctypes.macholib.dyld ...
freezing ctypes.macholib.dylib ...
freezing ctypes.macholib.framework ...
freezing ctypes.util ...
freezing difflib ...
freezing dis ...
freezing distutils ...
freezing distutils.dep_util ...
freezing distutils.errors ...
freezing distutils.log ...
freezing distutils.spawn ...
freezing distutils.sysconfig ...
freezing distutils.text_file ...
freezing distutils.util ...
freezing doctest ...
freezing dummy_thread ...
freezing dummy_threading ...
freezing email ...
freezing email._parseaddr ...
freezing email.base64mime ...
freezing email.charset ...
freezing email.encoders ...
freezing email.errors ...
freezing email.feedparser ...
freezing email.message ...
freezing email.mime ...
freezing email.parser ...
freezing email.quoprimime ...
freezing email.utils ...
freezing encodings ...
freezing encodings.aliases ...
freezing fnmatch ...
freezing formatter ...
freezing ftplib ...
freezing functools ...
freezing genericpath ...
freezing getopt ...
freezing getpass ...
freezing gettext ...
freezing glob ...
freezing heapq ...
freezing httplib ...
freezing inspect ...
freezing keyword ...
freezing linecache ...
freezing locale ...
freezing macurl2path ...
freezing mimetools ...
freezing mimetypes ...
freezing ntpath ...
freezing nturl2path ...
freezing opcode ...
freezing optparse ...
freezing os ...
freezing os2emxpath ...
freezing pdb ...
freezing pickle ...
freezing pkgutil ...
freezing posixpath ...
freezing pprint ...
freezing py_compile ...
freezing pydoc ...
freezing pydoc_topics ...
freezing quopri ...
freezing random ...
freezing re ...
freezing repr ...
freezing rfc822 ...
freezing shlex ...
freezing site ...
freezing socket ...
freezing sre_compile ...
freezing sre_constants ...
freezing sre_parse ...
freezing ssl ...
freezing stat ...
freezing string ...
freezing struct ...
freezing subprocess ...
freezing tempfile ...
freezing textwrap ...
freezing threading ...
freezing token ...
freezing tokenize ...
freezing traceback ...
freezing tty ...
freezing types ...
freezing unittest ...
freezing urllib ...
freezing urlparse ...
freezing uu ...
freezing warnings ...
freezing webbrowser ...
generating table of frozen modules
Warning: unknown modules remain: _bisect _collections _ctypes _functools
_heapq _locale _ssl binascii
Now run "make" to build the target: hello
bash-3.2$ make
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c config.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c frozen.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_BaseHTTPServer.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_FixTk.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_SocketServer.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_StringIO.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_Tkconstants.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_Tkinter.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_UserDict.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M___future__.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M___main__.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M__abcoll.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M__threading_local.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_abc.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_base64.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_bdb.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_bisect.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_cmd.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_codecs.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_collections.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_copy.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_copy_reg.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ctypes.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ctypes___endian.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ctypes__macholib.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_ctypes__macholib__dyld.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_ctypes__macholib__dylib.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_ctypes__macholib__framework.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ctypes__util.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_difflib.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_dis.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_distutils.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_distutils__dep_util.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_distutils__errors.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_distutils__log.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_distutils__spawn.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_distutils__sysconfig.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_distutils__text_file.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_distutils__util.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_doctest.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_dummy_thread.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_dummy_threading.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email___parseaddr.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__base64mime.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__charset.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__encoders.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__errors.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__feedparser.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__message.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__mime.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__parser.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__quoprimime.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_email__utils.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_encodings.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c
M_encodings__aliases.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_fnmatch.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_formatter.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ftplib.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_functools.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_genericpath.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_getopt.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_getpass.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_gettext.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_glob.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_heapq.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_httplib.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_inspect.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_keyword.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_linecache.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_locale.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_macurl2path.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_mimetools.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_mimetypes.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ntpath.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_nturl2path.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_opcode.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_optparse.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_os.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_os2emxpath.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_pdb.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_pickle.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_pkgutil.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_posixpath.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_pprint.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_py_compile.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_pydoc.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_pydoc_topics.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_quopri.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_random.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_re.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_repr.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_rfc822.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_shlex.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_site.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_socket.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_sre_compile.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_sre_constants.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_sre_parse.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_ssl.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_stat.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_string.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_struct.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_subprocess.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_tempfile.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_textwrap.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_threading.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_token.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_tokenize.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_traceback.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_tty.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_types.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_unittest.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_urllib.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_urlparse.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_uu.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_warnings.c
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6
-I/fnal/ups/prd/python/v2_6_2_E_0/include/python2.6 -c M_webbrowser.c
gcc -pthread  -Xlinker -export-dynamic config.o frozen.o
M_BaseHTTPServer.o M_FixTk.o M_SocketServer.o M_StringIO.o
M_Tkconstants.o M_Tkinter.o M_UserDict.o M___future__.o M___main__.o
M__abcoll.o M__threading_local.o M_abc.o M_base64.o M_bdb.o M_bisect.o
M_cmd.o M_codecs.o M_collections.o M_copy.o M_copy_reg.o M_ctypes.o
M_ctypes___endian.o M_ctypes__macholib.o M_ctypes__macholib__dyld.o
M_ctypes__macholib__dylib.o M_ctypes__macholib__framework.o
M_ctypes__util.o M_difflib.o M_dis.o M_distutils.o
M_distutils__dep_util.o M_distutils__errors.o M_distutils__log.o
M_distutils__spawn.o M_distutils__sysconfig.o M_distutils__text_file.o
M_distutils__util.o M_doctest.o M_dummy_thread.o M_dummy_threading.o
M_email.o M_email___parseaddr.o M_email__base64mime.o M_email__charset.o
M_email__encoders.o M_email__errors.o M_email__feedparser.o
M_email__message.o M_email__mime.o M_email__parser.o
M_email__quoprimime.o M_email__utils.o M_encodings.o
M_encodings__aliases.o M_fnmatch.o M_formatter.o M_ftplib.o
M_functools.o M_genericpath.o M_getopt.o M_getpass.o M_gettext.o
M_glob.o M_heapq.o M_httplib.o M_inspect.o M_keyword.o M_linecache.o
M_locale.o M_macurl2path.o M_mimetools.o M_mimetypes.o M_ntpath.o
M_nturl2path.o M_opcode.o M_optparse.o M_os.o M_os2emxpath.o M_pdb.o
M_pickle.o M_pkgutil.o M_posixpath.o M_pprint.o M_py_compile.o M_pydoc.o
M_pydoc_topics.o M_quopri.o M_random.o M_re.o M_repr.o M_rfc822.o
M_shlex.o M_site.o M_socket.o M_sre_compile.o M_sre_constants.o
M_sre_parse.o M_ssl.o M_stat.o M_string.o M_struct.o M_subprocess.o
M_tempfile.o M_textwrap.o M_threading.o M_token.o M_tokenize.o
M_traceback.o M_tty.o M_types.o M_unittest.o M_urllib.o M_urlparse.o
M_uu.o M_warnings.o M_webbrowser.o
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/config/libpython2.6.a
-lreadline -ltermcap                  -L/usr/lib64 -ltk8.4 -ltcl8.4
-L/usr/X11R6/lib -lX11     -L/fnal/ups/prd/python/v2_6_2_E_0/lib -lz 
-lpthread -ldl  -lutil -lm  -o hello
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/config/libpython2.6.a(posixmodule.o):
In function `posix_tmpnam':
/fnal/ups/prd/python/v2_6_2_E_0/Python-2.6.2/./Modules/posixmodule.c:7129:
warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/fnal/ups/prd/python/v2_6_2_E_0/lib/python2.6/config/libpython2.6.a(posixmodule.o):
In function `posix_tempnam':
/fnal/ups/prd/python/v2_6_2_E_0/Python-2.6.2/./Modules/posixmodule.c:7084:
warning: the use of `tempnam' is dangerous, better use `mkstemp'
config.o:(.data+0x68): undefined reference to `init_warnings'
collect2: ld returned 1 exit status
make: *** [hello] Error 1

----------
components: Build
messages: 88156
nosy: mzalokar
severity: normal
status: open
title: freeze.py doesn't work
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu May 21 18:11:59 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Thu, 21 May 2009 16:11:59 +0000
Subject: [New-bugs-announce] [issue6079] SyntaxError in xmlrpc.client Fault
	example
In-Reply-To: <1242922319.61.0.524994134376.issue6079@psf.upfronthosting.co.za>
Message-ID: <1242922319.61.0.524994134376.issue6079@psf.upfronthosting.co.za>


New submission from Thijs Triemstra <lists at collab.nl>:

The example is defined as:

import xmlrpc.client

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
try:
    proxy.add(2, 5)
except xmlrpc.client.Fault, err:
    print("A fault occurred")
    print("Fault code: %d" % err.faultCode)
    print("Fault string: %s" % err.faultString)

Which throws the following error:

  File "test.py", line 6
    except xmlrpc.client.Fault, err:
                              ^
SyntaxError: invalid syntax

I think it should be defined instead as:

import xmlrpc.client

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
try:
    proxy.add(2, 5)
except xmlrpc.client.Fault as err:
    print("A fault occurred")
    print("Fault code: %d" % err.faultCode)
    print("Fault string: %s" % err.faultString)

----------
assignee: georg.brandl
components: Documentation
messages: 88162
nosy: georg.brandl, thijs
severity: normal
status: open
title: SyntaxError in xmlrpc.client Fault example
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Thu May 21 22:34:20 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 21 May 2009 20:34:20 +0000
Subject: [New-bugs-announce] [issue6080] Itertools objects are missing "send"
In-Reply-To: <1242938060.5.0.00936464962761.issue6080@psf.upfronthosting.co.za>
Message-ID: <1242938060.5.0.00936464962761.issue6080@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

Some (most?) of the itertools functions "generators" do not supprt "send".

>>> from itertools import count
>>> n = count(0)
>>> n.next()
0
>>> n.send(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'itertools.count' object has no attribute 'send'
>>> 

However:
>>> def count(start):
...     while 1:
...         yield start
...         start += 1
... 
>>> n = count(0)
>>> n.next()
0
>>> n.send(1)
1
>>> 

For some of the functions (such as count and repeat), "send" also make
sense.

----------
components: Library (Lib)
messages: 88166
nosy: tebeka
severity: normal
status: open
title: Itertools objects are missing "send"
versions: Python 2.7

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

From report at bugs.python.org  Fri May 22 01:23:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 May 2009 23:23:16 +0000
Subject: [New-bugs-announce] [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>


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

The old % formatting allowed arbitrary mappings:

  >>> class Default(dict):
  ...     def __missing__(self, key):
  ...         return key
  ...
  >>> s = '%(name)s was born in %(country)s'
  >>> s % Default(name='Guido')
  'Guido was born in country'

But the new str.format() demands mappings be first converted to a
regular dict using **kwargs, so something like the above is not possible.

  >>> s = '{name} was born in {country}'
  >>> s.format(**Default(name='Guido'))
  Traceback (most recent call last):
    File "<pyshell#27>", line 1, in <module>
      s.format(**Default(name='Guido'))
  KeyError: 'country'

There is a work-around using string.vformat() but it is obscure and awkward:

  >>> import string
  >>> string.Formatter().vformat(s, (), Default(name='Guido'))
  'Guido was born in country'

Instead, it would be better to offer an alternate method:

  >>> s.format_from_mapping(Default(name='Guido'))
  'Guido was born in country'

----------
messages: 88173
nosy: rhettinger
severity: normal
status: open
title: str.format_from_mapping()
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May 22 02:56:49 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Fri, 22 May 2009 00:56:49 +0000
Subject: [New-bugs-announce] [issue6082] os.path.sameopenfile reports that
	standard streams are	the same
In-Reply-To: <1242953809.47.0.424707579348.issue6082@psf.upfronthosting.co.za>
Message-ID: <1242953809.47.0.424707579348.issue6082@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

Python 2.6.1 (r261:67515, Apr  2 2009, 18:25:55)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, os
>>> os.path.sameopenfile(sys.stdin.fileno(), sys.stdout.fileno())
True
>>> os.path.sameopenfile(sys.stdout.fileno(), sys.stderr.fileno())
True
>>> null = open(os.devnull)
>>> os.path.sameopenfile(sys.stdin.fileno(), null.fileno())
False
>>> # That worked.

----------
components: Library (Lib)
messages: 88174
nosy: ryles
severity: normal
status: open
title: os.path.sameopenfile reports that standard streams are the same
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri May 22 10:18:56 2009
From: report at bugs.python.org (Bill McCloskey)
Date: Fri, 22 May 2009 08:18:56 +0000
Subject: [New-bugs-announce] [issue6083] Reference counting bug in setrlimit
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>


New submission from Bill McCloskey <billm at cs.berkeley.edu>:

The code for resource_setrlimit in Modules/resource.c does not handle
reference counting properly. The following Python code segfaults for me
on Ubuntu 8.10 in Python 2.5.2 and also a custom-built 2.6.1.

--
import resource

l = [0, 0]

class MyNum:
    def __int__(self):
        l[1] = 20
        return 10

    def __del__(self):
        print 'byebye', self

l[0] = MyNum()
l[1] = MyNum()
resource.setrlimit(resource.RLIMIT_CPU, l)
--

The problem is that setrlimit gets its arguments by calling:
   PyArg_ParseTuple(args, "i(OO):setrlimit", 
                    &resource, &curobj, &maxobj)
The references curobj and maxobj are borrowed. The second argument can
be passed as a mutable list rather than a tuple, so it's possible to
update the list in the middle of setrlimit, causing maxobj to be
destroyed before setrlimit is done with it.

I've attached a patch that INCREFs both variables immediately after
parsing them to avoid this problem.

In my opinion it seems dangerous to allow format strings with the 'O'
specifier appearing in parentheses. You normally expect that objects
returned from PyArg_ParseTuple are pretty safe, but the fact that the
inner sequence may be mutable violates this assumption. Might it make
sense to ban this use case? I only found one other instance of it in the
Python source tree, inside ctypes. This one may also be a crashing
bug--I didn't look at it carefully enough.

----------
components: Extension Modules
files: python-bug-01.patch
keywords: patch
messages: 88181
nosy: billm
severity: normal
status: open
title: Reference counting bug in setrlimit
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14040/python-bug-01.patch

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

From report at bugs.python.org  Fri May 22 11:17:51 2009
From: report at bugs.python.org (bones7456)
Date: Fri, 22 May 2009 09:17:51 +0000
Subject: [New-bugs-announce] [issue6084] documentation of zip function is
	error
In-Reply-To: <1242983871.03.0.567968513766.issue6084@psf.upfronthosting.co.za>
Message-ID: <1242983871.03.0.567968513766.issue6084@psf.upfronthosting.co.za>


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

http://docs.python.org/library/functions.html?highlight=zip#zip

In this page, the example is error:

Python 2.6.2 (r262:71600, Apr 24 2009, 10:04:30) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1, 2, 3]
>>> y = [4, 5, 6]
>>> zipped = zip(x, y)
>>> zipped
[(1, 4), (2, 5), (3, 6)]
>>> x2, y2 = zip(*zipped)
>>> x == x2, y == y2
(False, False)

The last line is "(False, False)", not True.

----------
assignee: georg.brandl
components: Documentation
messages: 88182
nosy: bones7456, georg.brandl
severity: normal
status: open
title: documentation of zip function is error
versions: Python 2.6

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

From report at bugs.python.org  Fri May 22 12:12:40 2009
From: report at bugs.python.org (Wentao Han)
Date: Fri, 22 May 2009 10:12:40 +0000
Subject: [New-bugs-announce] [issue6085] Logging in
	BaseHTTPServer.BaseHTTPRequestHandler causes	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>


New submission from Wentao Han <wentao.han at gmail.com>:

The invocation of socket.getfqdn to get FQDN of the host may delay for 
several seconds on some platforms when no appropriate host name is found. 
This causes lag when using SimpleXMLRPCServer and other class derived from 
BaseHTTPServer for every request.

----------
components: Library (Lib)
messages: 88188
nosy: aerodonkey
severity: normal
status: open
title: Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Fri May 22 12:29:51 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Fri, 22 May 2009 10:29:51 +0000
Subject: [New-bugs-announce] [issue6086] Correct minor typos in
	doanddont.rst and urllib2.rst	howto documents.
In-Reply-To: <1242988191.07.0.296815205592.issue6086@psf.upfronthosting.co.za>
Message-ID: <1242988191.07.0.296815205592.issue6086@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached are two patches (for trunk and py3k):

* Correct a trivial typo in doanddont.rst

* Correct a mistake in urllib2.rst, where URLError was being used
instead of the HTTPError, in case the urllib2.urlopen() was raising an
exception.

----------
assignee: georg.brandl
components: Documentation
messages: 88189
nosy: georg.brandl, vshenoy
severity: normal
status: open
title: Correct minor typos in doanddont.rst and urllib2.rst howto documents.
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri May 22 14:39:10 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 22 May 2009 12:39:10 +0000
Subject: [New-bugs-announce] [issue6087] distutils.sysconfig.get_python_lib
	gives surprising	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

When used with a build from source (i.e. non-installed) of Python,
get_python_lib gives the result (on Linux)

[prefix]/lib/python[version]

Shouldn't this be [prefix]/Lib?

Note that get_python_inc() returns "Include". That's because it makes
use of the "python_build" flag which is set for builds from source.

----------
assignee: tarek
components: Distutils
keywords: easy
messages: 88194
nosy: tarek, vsajip
priority: normal
severity: normal
status: open
title: distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri May 22 17:52:25 2009
From: report at bugs.python.org (Leeon)
Date: Fri, 22 May 2009 15:52:25 +0000
Subject: [New-bugs-announce] [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: <1243007545.21.0.68248439701.issue6088@psf.upfronthosting.co.za>


New submission from Leeon <leeon.li at ca.com>:

Python3.0.1 is not available when system locale is zh_TW.eucTW

Expected result: python3.0 interpreter should works fine.
Actual result: python3.0 interpreter can not execute any statement or
ran python program.

Steps to reproduce this bug:
1. Login HP-UX with a locale 'zh_TW.eucTW'.
2. Install ActivePython-3.0.1.1-hpux11.00-parisc.tar.gz on a HP-UX 11.11
machine.
3. Start the python3.0 interpreter.
4. Try some python statements like following, there was not any reaction:
    import locale
    locale.getlocale()
    help()
    exit()
5. Try to run a python program like following, but it was not run.
    python3.0 foo.py

Notes:
1. This error does not occur when the system locale is 'zh_TW.big5'.
2. This error was also found on linux build.

----------
components: Interpreter Core
messages: 88195
nosy: leeon
severity: normal
status: open
title: Python3.0.1.1 is not available when system locale is zh_TW.eucTW
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri May 22 18:24:41 2009
From: report at bugs.python.org (Mark Florisson)
Date: Fri, 22 May 2009 16:24:41 +0000
Subject: [New-bugs-announce] [issue6089] str.format raises SystemError
In-Reply-To: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>
Message-ID: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

>>> '{0[0](10)}'.format([None])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: error return without exception set

----------
components: Interpreter Core
messages: 88198
nosy: eggy
severity: normal
status: open
title: str.format raises SystemError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May 22 18:50:59 2009
From: report at bugs.python.org (Ivan Bykov)
Date: Fri, 22 May 2009 16:50:59 +0000
Subject: [New-bugs-announce] [issue6090] zipfile DeprecationWarning Python
	2.6.2
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>


New submission from Ivan Bykov <ivan.bykov at gmail.com>:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit 
(Intel)] on win32
IDLE 2.6.2      
>>> import zipfile
>>> new = zipfile.ZipFile('C:\\x', 'w', zipfile.ZIP_DEFLATED)
>>> zi = zipfile.ZipInfo('test',(1,2,3,4,5,6))
>>> new.writestr(zi,'fgh')

Warning (from warnings module):
  File "H:\programs\python\lib\zipfile.py", line 1105
    self.fp.write(zinfo.FileHeader())
DeprecationWarning: struct integer overflow masking is deprecated

Warning (from warnings module):
  File "H:\programs\python\lib\zipfile.py", line 1105
    self.fp.write(zinfo.FileHeader())
DeprecationWarning: 'H' format requires 0 <= number <= 65535
>>>

----------
components: Extension Modules
messages: 88201
nosy: ivb
severity: normal
status: open
title: zipfile DeprecationWarning Python 2.6.2
versions: Python 2.6

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

From martin at v.loewis.de  Fri May 22 21:12:50 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 May 2009 21:12:50 +0200
Subject: [New-bugs-announce] [issue6067] make error
In-Reply-To: <1242810066.3.0.038429040919.issue6067@psf.upfronthosting.co.za>
References: <1242810066.3.0.038429040919.issue6067@psf.upfronthosting.co.za>
Message-ID: <4A16F932.7060409@v.loewis.de>

> please help my!

Please understand that the Python bug tracker is not a place
to obtain help. Instead, it is a place for you to help Python.

Please find out
a) whether mbstate_t is defined in your system, and (if so)
b) what header file needs to be included to get the type
   definition

From report at bugs.python.org  Sat May 23 04:10:28 2009
From: report at bugs.python.org (Jack Miller)
Date: Sat, 23 May 2009 02:10:28 +0000
Subject: [New-bugs-announce] [issue6091] Curses segfaulting in FreeBSD/amd64
In-Reply-To: <1243044628.32.0.644486843257.issue6091@psf.upfronthosting.co.za>
Message-ID: <1243044628.32.0.644486843257.issue6091@psf.upfronthosting.co.za>


New submission from Jack Miller <jack at codezen.org>:

I have some code that gets a Pycurses window object, grabs the standard
ncurses WINDOW* out of it and proceeds to use that as usual. Works great
on Linux. Segfaults on FreeBSD/amd64.

static PyObject * mvw(PyObject *self, PyObject *args)
{
    PyObject *window;
    WINDOW *win;
    int y, x, width, rep_len, end_len, ret;
    char *message, *rep, *end;

    const char *m_enc, *r_enc, *e_enc;
    if(!PyArg_ParseTuple(args, "Oiiietetet", 
                &window, &y, &x, &width, &m_enc, &message,
                &r_enc, &rep, &e_enc, &end))
            return NULL;

    if (window != Py_None)
        win = ((PyCursesWindowObject *)window)->win;
    else
        win = NULL;
    ...

Very simple. After this runs, `win` should be a standard curses window.
As noted, this works just fine in Linux regardless of architecture and
I'm sure that I'm passing a correct object type. (Tangentially, the
window check macro in py_curses.h -- PyCursesWindow_Check(v) -- also
segfaults, but I haven't tested that on Linux).

The subsequent `win` is non-NULL, but when I attempt to actually use it,
even for a simple `mvwaddch(win, 0, 0, '?');`, the program segfaults on
FreeBSD.

Other Notes: If I just use curses from Python (i.e. without a C
extension), it works as expected. I've attached this basic, working
test. This leads me to believe that the ncurses library is ok, and that
the majority of the curses binding is probably ok.

Also, I'm not sure if there is a better (more pythonic) way to get to
the WINDOW object, I just looked at the struct in py_curses.h to grab it
and it worked, so I didn't give it a second thought until now. I also
don't know how to verify that the pointer points to a curses WINDOW, but
I do know that the pointer address looks ok.

I can whip up a non-working test case on request, but I'm not sure the
best way to include the extension. The full source for the extension and
the program using it at codezen.org/canto ( particularly: 
http://codezen.org/cgi-bin/gitweb.cgi?p=canto.git;a=blob;f=canto/widecurse.c;h=d8a259a66c85f5fa87d52045a643fc81beec8017;hb=HEAD
)

I'm running FreeBSD 8-CURRENT, but the code doesn't work on 7.2-STABLE
either. This is Python 2.5.4 and pyncurses 0.3 both built from source
out of ports as of May 20th.

----------
components: Extension Modules
messages: 88220
nosy: themoken
severity: normal
status: open
title: Curses segfaulting in FreeBSD/amd64
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Sat May 23 08:38:54 2009
From: report at bugs.python.org (jamesie)
Date: Sat, 23 May 2009 06:38:54 +0000
Subject: [New-bugs-announce] [issue6092] Changed Shortcuts don't show up in
	menu
In-Reply-To: <1243060734.82.0.446246510061.issue6092@psf.upfronthosting.co.za>
Message-ID: <1243060734.82.0.446246510061.issue6092@psf.upfronthosting.co.za>


New submission from jamesie <post06 at jamesie.de>:

After having changed the key binding for run-module to C-r it still says
F5 in the menu and in the general section of configuration.
Check Module has the same behaviour.
Seen with Debian Lenny's IDLE 1.2.2 on Python 2.5.2 and with IDLE 3.1b1
on Python 3.1b1.

----------
components: IDLE
messages: 88224
nosy: gpolo, jamesie
severity: normal
status: open
title: Changed Shortcuts don't show up in menu
versions: Python 2.5, Python 3.1

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

From report at bugs.python.org  Sat May 23 10:48:45 2009
From: report at bugs.python.org (Tuomas Vesterinen)
Date: Sat, 23 May 2009 08:48:45 +0000
Subject: [New-bugs-announce] [issue6093] Ambiguous locale.strxfrm
In-Reply-To: <1243068525.81.0.468614425869.issue6093@psf.upfronthosting.co.za>
Message-ID: <1243068525.81.0.468614425869.issue6093@psf.upfronthosting.co.za>


New submission from Tuomas Vesterinen <tuomas.vesterinen at iki.fi>:

This was fixed once in Python 2.5, but in Python 3.0 the bug celebrates
its comeback. The tail of the strxfrm result is ambiguous.

Python 3.0.1 (r301:69556, Apr 14 2009, 14:30:31)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_COLLATE, 'en_US.utf8')
'en_US.utf8'
>>> key1=locale.strxfrm('maupassant guy')
>>>> for i in range(10):
...     print(locale.strxfrm('maupassant guy')==key1)
...
False
True
False
False
False
False
False
False
False
False

----------
components: Library (Lib)
messages: 88226
nosy: tuves
severity: normal
status: open
title: Ambiguous locale.strxfrm
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sat May 23 20:19:58 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 May 2009 18:19:58 +0000
Subject: [New-bugs-announce] [issue6094] Python fails to build with
	Subversion 1.7
In-Reply-To: <1243102798.53.0.847495660834.issue6094@psf.upfronthosting.co.za>
Message-ID: <1243102798.53.0.847495660834.issue6094@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

svnversion program from Subversion 1.7 (currently trunk), when invoked
on unversioned directory, prints "Unversioned directory" instead
"exported". This change in output is intentional and won't be reverted.

It causes build failure:
x86_64-pc-linux-gnu-gcc -pthread -c -fno-strict-aliasing -DNDEBUG -
-DSVNVERSION=\"`LC_ALL=C svnversion .`\" -o Modules/getbuildinfo.o
./Modules/getbuildinfo.c                                                                                                                                              
x86_64-pc-linux-gnu-gcc: directory": No such file or directory                                                                                               
<command-line>: warning: missing terminating " character                                                                                                     
./Modules/getbuildinfo.c: In function '_Py_svnversion':                                                                                                      
./Modules/getbuildinfo.c:48: error: missing terminating " character                                                                                          
./Modules/getbuildinfo.c:48: error: expected expression before ';'
token                                                                                     
make: *** [Modules/getbuildinfo.o] Error 1

I'm attaching the patch which fixes this problem and also updates
expected output of svnversion.

----------
components: Build
files: python-2.6.2-svnversion.patch
keywords: patch
messages: 88246
nosy: Arfrever
severity: normal
status: open
title: Python fails to build with Subversion 1.7
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14045/python-2.6.2-svnversion.patch

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

From report at bugs.python.org  Sun May 24 01:54:46 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 May 2009 23:54:46 +0000
Subject: [New-bugs-announce] [issue6095] os.curdir as the default argument
	for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>


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

make os.listdir() path argument be os.curdir.

I am working on a patch, I'll submit here

----------
components: Library (Lib)
messages: 88256
nosy: tarek
severity: normal
status: open
title: os.curdir as the default argument for os.listdir
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun May 24 19:06:50 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 24 May 2009 17:06:50 +0000
Subject: [New-bugs-announce] [issue6096] SimpleXMLRPCServer not suitable for
	HTTP/1.1 keep-alive
In-Reply-To: <1243184810.28.0.183866106023.issue6096@psf.upfronthosting.co.za>
Message-ID: <1243184810.28.0.183866106023.issue6096@psf.upfronthosting.co.za>


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

The SimpleXMRRPCServer class calls connection.shutdown(1) when done with 
each request, thus making it unsuitable for a RequestHandler that supports 
HTTP/1.1 with keep-alive.  This patch removes those extra shutdown calls.
Patch also uploaded as 
http://codereview.appspot.com/63143

----------
components: Library (Lib)
files: xmlsrv.patch
keywords: easy, needs review, patch, patch
messages: 88269
nosy: krisvale
severity: normal
status: open
title: SimpleXMLRPCServer not suitable for HTTP/1.1 keep-alive
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14053/xmlsrv.patch

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

From report at bugs.python.org  Sun May 24 20:03:32 2009
From: report at bugs.python.org (David Watson)
Date: Sun, 24 May 2009 18:03:32 +0000
Subject: [New-bugs-announce] [issue6097] Encoded surrogate characters on
	command line not escaped	in sys.argv
In-Reply-To: <1243188212.8.0.809518325398.issue6097@psf.upfronthosting.co.za>
Message-ID: <1243188212.8.0.809518325398.issue6097@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

The mbstowcs and mbrtwoc functions which are used for the initial
conversion of command-line arguments on Unix can return lone or
paired surrogates (e.g. \udcff for \xed\xb3\xbf in non-strict
UTF-8), and these surrogates are currently placed into sys.argv
unescaped.  This creates various problems such as strings that
cannot be re-encoded into bytes and strings that could represent
more than one byte sequence.  Examples follow using the following
script in a UTF-8 locale on Linux:

import sys
print(repr(sys.argv[1]))
print(repr(sys.argv[1].encode(sys.getfilesystemencoding(),
"surrogateescape")))


Strings that cannot be re-encoded:

$ ./python argtest.py $'\xed\xa0\x80'
'\ud800'
Traceback (most recent call last):
  File "argtest.py", line 6, in <module>
    print(repr(sys.argv[1].encode(sys.getfilesystemencoding(),
"surrogateescape")))
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in
position 0: surrogates not allowed

$ ./python argtest.py $'\xed\xb0\x80'
'\udc00'
Traceback (most recent call last):
  File "argtest.py", line 6, in <module>
    print(repr(sys.argv[1].encode(sys.getfilesystemencoding(),
"surrogateescape")))
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc00' in
position 0: surrogates not allowed


Aliasing between non-decodable bytes and encoded lone surrogates:

$ ./python argtest.py $'\xff'
'\udcff'
b'\xff'

$ ./python argtest.py $'\xed\xb3\xbf'
'\udcff'
b'\xff'


Aliasing between encoding of a non-BMP character and encoding of
its UTF-16 representation (on narrow Unicode builds):

$ ./python argtest.py $'\xf0\x90\x80\x80'
'\U00010000'
b'\xf0\x90\x80\x80'

$ ./python argtest.py $'\xed\xa0\x80\xed\xb0\x80'
'\U00010000'
b'\xf0\x90\x80\x80'


Attached is a patch to fix these problems by replacing any
decoded characters in the range 0xd800...0xdfff with the
surrogateescape encodings of their source bytes.

----------
files: escape-surrogates.diff
keywords: patch
messages: 88272
nosy: baikie
severity: normal
status: open
title: Encoded surrogate characters on command line not escaped in sys.argv
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14054/escape-surrogates.diff

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

From report at bugs.python.org  Sun May 24 22:43:00 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sun, 24 May 2009 20:43:00 +0000
Subject: [New-bugs-announce] [issue6098] xml.dom.minidom incorrectly claims
	DOM Level 3 conformance
In-Reply-To: <1243197780.58.0.272636351535.issue6098@psf.upfronthosting.co.za>
Message-ID: <1243197780.58.0.272636351535.issue6098@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister <phihag at phihag.de>:

>From DOM Level 3[1]: "An implementation conforms to a DOM Level 3 module
if it supports all the interfaces for that module and the associated
semantics.". minidom supports only some Level 3 functions such as
Node.renameNode, Element.setIdAttribute*, Text.replaceWholeText and
Node.isSameNode.

Apart from full DOM Level 2 conformance such as functional namespace
handling, many semantics are available under a different name, such as
DOMImplementation.getFeature (minidom: getInterface),
Text.getWholeText(minidom: _getWholeText) or missing
(Attr.schemaTypeInfo, Document.inputEncoding, Document.xmlEncoding,
Document.xmlStandalone, Document.xmlVersion, Document.domConfig,
Document.adoptNode, Document.normalizeDocument,
DOMException.VALIDATION_ERR, DOMException.TYPE_MISMATCH_ERR,
Node.baseURI, Node.textContent, Node.compareDocumentPosition,
Node.lookupPrefix, Node.isDefaultNamespace, Node.lookupNamespaceURI,
Node.isEqualNode, Node.DOCUMENT_POSITION_*,
Text.isElementContentWhitespace).

Users explicitely asking for DOM Level 3 conformance will run into
unexpected problems. Attached is a patch that removes the DOM L3
conformance declarations.

----------
components: XML
files: minidom-dont-declare-level3.diff
keywords: patch
messages: 88282
nosy: phihag
severity: normal
status: open
title: xml.dom.minidom incorrectly claims DOM Level 3 conformance
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14058/minidom-dont-declare-level3.diff

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

From report at bugs.python.org  Sun May 24 22:52:12 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 24 May 2009 20:52:12 +0000
Subject: [New-bugs-announce] [issue6099] HTTP/1.1 with keep-alive support
	for xmlrpclib.ServerProxy
In-Reply-To: <1243198332.08.0.299017339998.issue6099@psf.upfronthosting.co.za>
Message-ID: <1243198332.08.0.299017339998.issue6099@psf.upfronthosting.co.za>


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

The Transport class in xmlrpclib.py was using the old httplib.HTTP 
class.
This patch brings xmlrpclib up to date to use the HTTPConnection and 
HTTPSConnection classes.  This allows xlmrpclib.ServerProxy to use 
HTTP/1.1 with keep-alive on
servers that support it.

Note that this patch benefits from recent optimizations of 
HTTPConnection reducing the Nagle problem.

This is a separate patch from http://bugs.python.org/issue1767370 and in 
my opinion much simpler.
See also 
http://bugs.python.org/issue2076

Patch uploaded as http://codereview.appspot.com/63144

----------
components: Library (Lib)
files: xmlprclib.patch
keywords: needs review, patch, patch
messages: 88283
nosy: krisvale
severity: normal
status: open
title: HTTP/1.1 with keep-alive support for xmlrpclib.ServerProxy
type: performance
versions: Python 2.7, Python 3.0
Added file: http://bugs.python.org/file14059/xmlprclib.patch

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

From report at bugs.python.org  Mon May 25 00:30:12 2009
From: report at bugs.python.org (marek_sp)
Date: Sun, 24 May 2009 22:30:12 +0000
Subject: [New-bugs-announce] [issue6100] Expanding arrays inside other arrays
In-Reply-To: <1243204212.24.0.875545210222.issue6100@psf.upfronthosting.co.za>
Message-ID: <1243204212.24.0.875545210222.issue6100@psf.upfronthosting.co.za>


New submission from marek_sp <marek_sp at tlen.pl>:

Hello!
I recently thought about a nice feature (pure syntactic sugar):
>>> a = [2,3,4]
>>> b = [1,*a,5]
>>> print b
[1, 2, 3 ,4 ,5]

instead of:
>>> b = [1]+a+[5]

I think first one is somewhat more readable and similiar thing already
is possible with function calls. For example:
>>> c = func(*a)

----------
components: Interpreter Core
messages: 88292
nosy: marek_sp
severity: normal
status: open
title: Expanding arrays inside other arrays
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon May 25 01:31:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 May 2009 23:31:37 +0000
Subject: [New-bugs-announce] [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This patch condenses the many current opcodes used to start a with
statement into one, SETUP_WITH. I originally did this to properly lookup
__enter__ and __exit__ as special methods. However, the patch also has
the nice side effect of removing the need for a temporary variable.

----------
assignee: benjamin.peterson
components: Interpreter Core
files: SETUP_WITH.patch
keywords: patch
messages: 88293
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: SETUP_WITH
type: performance
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14060/SETUP_WITH.patch

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

From report at bugs.python.org  Mon May 25 03:56:56 2009
From: report at bugs.python.org (Suzumizaki)
Date: Mon, 25 May 2009 01:56:56 +0000
Subject: [New-bugs-announce] [issue6102] When the package has non-ascii path
	and .pyc file, we cannot import them.
In-Reply-To: <1243216616.61.0.580341646155.issue6102@psf.upfronthosting.co.za>
Message-ID: <1243216616.61.0.580341646155.issue6102@psf.upfronthosting.co.za>


New submission from Suzumizaki <suzumizaki at free.japandesign.ne.jp>:

When the path of the package has non-ascii characters, importing such
packages always fails except the first time (in other words, always 
fails when compiled .pyc file exists).

The problem exists even the names of such modules only consist of
us-ascii characters. Please follow the test code I create, which can
test the problem even with English version Windows(, I expected).

Target: Windows XP (I tested Home Ed., SP3, 32bit, Japanase version)
Python: 3.0.1

The priority of this issue might be CRITICAL or higher by 2 reasons:
1) When the end-users meet this condition, the users cannot find what's
wrong easily, because UnicodeDecodeError is raised (not ImportError).

2) On non-English version Windows, "Desktop", "My Documents" or etc. 
folders have non-English name as default. For example, Katakana is used
in Japanese version. This means all python packages in the desktop meet
 this problem for not a few users.

----------
components: None
files: testcode.zip
messages: 88299
nosy: Suzumizaki
severity: normal
status: open
title: When the package has non-ascii path and .pyc file, we cannot import them.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file14063/testcode.zip

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

From report at bugs.python.org  Mon May 25 07:26:14 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 May 2009 05:26:14 +0000
Subject: [New-bugs-announce] [issue6103] Static library (libpythonX.Y.a)
	installed in incorrect	location
In-Reply-To: <1243229174.04.0.856181043806.issue6103@psf.upfronthosting.co.za>
Message-ID: <1243229174.04.0.856181043806.issue6103@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

When Python has been configured without --enable-shared option, then
`make install` installs $(LIBDIR)/libpythonX.Y.a and
$(LIBDIR)/pythonX.Y/config/libpythonX.Y.a (these files are identical).

When Python has been configured with --enable-shared option, then `make
install` installs $(LIBDIR)/libpythonX.Y.so and
$(LIBDIR)/pythonX.Y/config/libpythonX.Y.a.
It is inconsistent and causes using of static library instead of shared
library when a program is linked using "-L$(LIBDIR)/pythonX.Y/config -
(It was reported at https://bugs.gentoo.org/show_bug.cgi?id=252372)

I suggest to install libpythonX.Y.a only in $(LIBDIR).

----------
components: Installation
files: python-2.6.2-fix_static_library_location.patch
keywords: patch
messages: 88302
nosy: Arfrever
severity: normal
status: open
title: Static library (libpythonX.Y.a) installed in incorrect location
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14065/python-2.6.2-fix_static_library_location.patch

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

From report at bugs.python.org  Mon May 25 09:39:04 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 May 2009 07:39:04 +0000
Subject: [New-bugs-announce] [issue6104] OSX framework builds fail after
	r72861 move of _locale	into core library
In-Reply-To: <1243237144.62.0.281871401059.issue6104@psf.upfronthosting.co.za>
Message-ID: <1243237144.62.0.281871401059.issue6104@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Undefined symbols:
 "_CFStringConvertEncodingToIANACharSetName", referenced from:
    _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
 "_CFStringGetSystemEncoding", referenced from:
    _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
 "_CFStringGetCStringPtr", referenced from:
   _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)

SOLUTION:
   add "-framework CoreFoundation" to Makefile target
   "$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)"
   build of temporary minimal framework bootstrap

----------
components: Build
files: patch-nad0025-py3k.txt
messages: 88304
nosy: benjamin.peterson, nad, ronaldoussoren
severity: normal
status: open
title: OSX framework builds fail after r72861 move of _locale into core library
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14066/patch-nad0025-py3k.txt

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

From report at bugs.python.org  Mon May 25 11:22:46 2009
From: report at bugs.python.org (Wang Chun)
Date: Mon, 25 May 2009 09:22:46 +0000
Subject: [New-bugs-announce] [issue6105] json.dumps doesn't respect
	OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>


New submission from Wang Chun <yaohua2000 at gmail.com>:

PEP-0372 and Issue 5381 both say json.dumps respect OrderedDict's 
iteration order, but the example in them do not work on my latest trunk 
build.

$ uname -a
Linux 12.38 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 
x86_64 x86_64 GNU/Linux
$ python2.7
Python 2.7a0 (trunk, May 21 2009, 08:00:00) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> from collections import OrderedDict
>>> items = [('one', 1), ('two', 2), ('three', 3), ('four', 4), ('five', 
5)]
>>> json.dumps(OrderedDict(items))
'{"four": 4, "three": 3, "five": 5, "two": 2, "one": 1}'

----------
components: Library (Lib)
messages: 88311
nosy: wangchun
severity: normal
status: open
title: json.dumps doesn't respect OrderedDict's iteration order
versions: Python 2.7

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

From report at bugs.python.org  Mon May 25 18:13:05 2009
From: report at bugs.python.org (Pal Subbiah)
Date: Mon, 25 May 2009 16:13:05 +0000
Subject: [New-bugs-announce] [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>


New submission from Pal Subbiah <pal.subbiah at gmail.com>:

The telnet-read_until does not read the pattern and returns b'' for 
line 15 in the file given.

----------
components: Library (Lib)
files: telnet_n.py
messages: 88319
nosy: ps
severity: normal
status: open
title: read_until
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file14068/telnet_n.py

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

From report at bugs.python.org  Tue May 26 02:26:48 2009
From: report at bugs.python.org (Alex James)
Date: Tue, 26 May 2009 00:26:48 +0000
Subject: [New-bugs-announce] [issue6107] Pipes fail to return subprocess
	output on Windows
Message-ID: <1243297608.32.0.181136078266.issue6107@psf.upfronthosting.co.za>


Changes by Alex James <ac.james at shaw.ca>:


----------
components: IO, Windows
nosy: ac.james
severity: normal
status: open
title: Pipes fail to return subprocess output on Windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue May 26 06:53:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 May 2009 04:53:18 +0000
Subject: [New-bugs-announce] [issue6108] unicode(exception) behaves
	differently on Py2.6 when	len(exception.args) > 1
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

On Python 2.5 str(exception) and unicode(exception) return the same text:
>>> err
UnicodeDecodeError('ascii', '\xc3\xa0', 0, 1, 'ordinal not in range(128)')
>>> str(err)
"'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in
range(128)"
>>> unicode(err)
u"'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in
range(128)"

On Python 2.6 unicode(exception) returns unicode(exception.args):
>>> err
UnicodeDecodeError('ascii', '\xc3\xa0', 0, 1, 'ordinal not in range(128)')
>>> str(err)
"'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in
range(128)"
>>> unicode(err)
u"('ascii', '\\xc3\\xa0', 0, 1, 'ordinal not in range(128)')"

This seems to affect only exceptions with more than 1 arg (e.g.
UnicodeErrors and SyntaxErrors). KeyError is also different (the '' are
missing with unicode()).

Note that when an exception like ValueError() is instantiated with more
than 1 arg even str() returns str(exception.args) on both Py2.5 and Py2.6.

Probably __str__() checks the number of args before returning a specific
message and if it doesn't match it returns str(self.args). __unicode__()
instead seems to always return unicode(self.args) on Py2.6.

Attached there's a script that prints the repr(), str() and unicode() of
some exceptions, run it on Py2.5 and Py2.6 to see the differences.

----------
components: Interpreter Core
files: unicode_exceptions.py
messages: 88330
nosy: ezio.melotti
severity: normal
status: open
title: unicode(exception) behaves differently on Py2.6 when len(exception.args) > 1
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14071/unicode_exceptions.py

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

From report at bugs.python.org  Tue May 26 08:50:02 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 06:50:02 +0000
Subject: [New-bugs-announce] [issue6109] IDLE rendering issue with oriental
	characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

IDLE has problems rendering some oriental characters on OSX.

One way to reproduce this:

* Start IDLE
* Open the "Preferences..." menu
* Scroll down in the list of fonts until you reach the 'Osaka' font

The font just below the Osaka font has a number of oriental characters 
in its name. Some of those characters are rendered as squares instead of 
the correct character.

The same problem crops up when you print oriental characters. I started 
looking into this because a user on the pythonmac-sig asked a question 
about this. I have a file that demonstrates the problem when you open 
it, but don't know yet if I can post that to the tracker.

----------
components: IDLE, Macintosh, Tkinter
messages: 88331
nosy: ronaldoussoren
severity: normal
status: open
title: IDLE rendering issue with oriental characters on OSX
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue May 26 08:51:52 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 06:51:52 +0000
Subject: [New-bugs-announce] [issue6110] IDLE has two "Preferences..."
	menu's on OSX
In-Reply-To: <1243320712.83.0.629462070436.issue6110@psf.upfronthosting.co.za>
Message-ID: <1243320712.83.0.629462070436.issue6110@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

With Python 2.7, but not 3.1 or 2.6, IDLE has two "Preferences..." menu's 
on OSX. 

This is on a OSX 10.5 system, with an installation of Tcl/Tk 8.4 in 
/Library/Frameworks.

----------
components: IDLE, Macintosh
messages: 88332
nosy: ronaldoussoren
severity: normal
status: open
title: IDLE has two "Preferences..." menu's on OSX
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue May 26 08:54:43 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 06:54:43 +0000
Subject: [New-bugs-announce] [issue6111] Impossible to change preferences in
	IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

It seems to be impossible to actually change preferences in IDLE when 
using Python 3.1, there are no problems with 2.6, 2.7 and 3.1.

How to reproduce:
* Open the "preferences menu"
* Pick a different font
* Choose "apply": nothing changes
* Choose "ok": dialog doesn't close
* Choose "cancel": dialog closes, but obviously no settings were changed.

----------
components: IDLE, Macintosh
messages: 88333
nosy: ronaldoussoren
severity: normal
status: open
title: Impossible to change preferences in IDLE
versions: Python 3.1

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

From report at bugs.python.org  Tue May 26 09:47:42 2009
From: report at bugs.python.org (Ivo Danihelka)
Date: Tue, 26 May 2009 07:47:42 +0000
Subject: [New-bugs-announce] [issue6112] scheduler.cancel does not raise
	RuntimeError
In-Reply-To: <1243324062.93.0.51733568857.issue6112@psf.upfronthosting.co.za>
Message-ID: <1243324062.93.0.51733568857.issue6112@psf.upfronthosting.co.za>


New submission from Ivo Danihelka <ivo at danihelka.net>:

There is a misleading documentation for module sched.
Method scheduler.cancel() does not raise RuntimeError.
It raises ValueError if the given event is not in the queue.

The RuntimeError is mentioned inside the module documentation
and also inside the method __doc__ string.

----------
assignee: georg.brandl
components: Documentation
messages: 88338
nosy: fidlej, georg.brandl
severity: normal
status: open
title: scheduler.cancel does not raise RuntimeError
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue May 26 10:54:03 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 08:54:03 +0000
Subject: [New-bugs-announce] [issue6113] Dupicate instances of classes in
	list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>


New submission from Matthew <matthew.baynham at gmail.com>:

What I intended was...
I create a list of DIFFERENT instances of the same class, I wanted them
to be different instances, with different values for the properties,
stressing the word "DIFFERENT".

What I originally did was...
The __init__ assigns default values for the properties (eg, iId = 0, and
sName = ''), then I would change to properties before adding it to the
list.  However, the list will contain the right number of elements, but
every element is the same instance of the class.

I resolved this by...
If I change __init__ such that I'm passing it parameters with values to
assign to the properties.  And then adding the instances of the class to
the list.  Then each element in the list is a different instance.  And
this made everything work.

----------
components: Windows
messages: 88340
nosy: mbaynham
severity: normal
status: open
title: Dupicate instances of classes in list
versions: Python 2.5

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

From report at bugs.python.org  Tue May 26 12:55:59 2009
From: report at bugs.python.org (Sven Rebhan)
Date: Tue, 26 May 2009 10:55:59 +0000
Subject: [New-bugs-announce] [issue6114] distutils build_ext path comparison
	only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>


New submission from Sven Rebhan <OdinsHorse at googlemail.com>:

If python is installed into a symlink'ed directory, the variables
"sys.exec_prefix" and "sys.executable" can contain different paths.
Therefore, the respective test in build_ext.py fails (line 202)
and a wrong library search directory (-L.) is set.

The attached patch fixes this issue, by using os.path.samefile() instead
of the string comparison to see whether two files are identical
irrespective of their paths.

----------
assignee: tarek
components: Distutils
files: python-2.5.2-build_ext-pathcompare.patch
keywords: patch
messages: 88351
nosy: sleipnir, tarek
severity: normal
status: open
title: distutils build_ext path comparison only based on strings
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14073/python-2.5.2-build_ext-pathcompare.patch

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

From report at bugs.python.org  Tue May 26 14:07:06 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Tue, 26 May 2009 12:07:06 +0000
Subject: [New-bugs-announce] [issue6115] Header and doc related to
	PyNumber_Divide and	PyNumber_InPlaceDivide should be removed in py3k
In-Reply-To: <1243339626.58.0.298559042978.issue6115@psf.upfronthosting.co.za>
Message-ID: <1243339626.58.0.298559042978.issue6115@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

As function implementation of PyNumber_Divide and PyNumber_InPlaceDivide
are already removed, there are still function declaration in abstract.h,
and also entries in document:
http://docs.python.org/dev/py3k/c-api/number.html?highlight=pynumber_divide

I got some symbol undefined problem because of this. Please see the
attached patch for fixing either the header and doc.

Thank you!

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: divide.patch
keywords: patch
messages: 88360
nosy: bhy, georg.brandl
severity: normal
status: open
title: Header and doc related to PyNumber_Divide and PyNumber_InPlaceDivide should be removed in py3k
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14078/divide.patch

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

From report at bugs.python.org  Tue May 26 17:27:06 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 26 May 2009 15:27:06 +0000
Subject: [New-bugs-announce] [issue6116] frame.f_locals keeps references to
	things for too long
In-Reply-To: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>
Message-ID: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

When a frame's f_locals attribute is accessed, one of two things happens:

  * If this is the first access, a new dictionary is created and it is
populated with the locals from the frame (since they are not stored
internally as a dictionary).  The dictionary is both saved and returned.
  * Otherwise, the previously saved dictionary is updated to reflect the
current locals of the frame and then returned.

This means that the lifetime of locals in the frame is strangely altered
if the frame's f_locals attribute is ever accessed.  In particular, the
locals are kept alive until the frame object is discarded or the
f_locals attribute is accessed again.

The drawback of this is that references to locals may be "leaked" in a
surprising and difficult to understand way.  Another is that when
debugging an application, this will cause objects to have a different
lifetime than they will when the application is run without the
debugger.  One way the former of these issues has manifest is described
in this Twisted bug report:

  http://twistedmatrix.com/trac/ticket/3853

There, I suggested three possible solutions, in the form of a
replacement API for the f_locals attribute which either:

    * Gave you a copy of the locals at the current time and didn't
pretend it would be automatically updated
    * Gave you a view onto the locals at the current time, instead of a
real dictionary, and didn't actually hold any references to the locals
itself, only granted access to the "canonical" locals data in the frame.
    * Gave you a real dictionary of the locals but didn't hold a strong
reference to that dictionary internally, so that if all external users
of the dictionary went away, the frame itself would also stop referring
to the locals.

----------
components: Interpreter Core
messages: 88365
nosy: exarkun
severity: normal
status: open
title: frame.f_locals keeps references to things for too long
type: behavior

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

From report at bugs.python.org  Tue May 26 18:03:59 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 26 May 2009 16:03:59 +0000
Subject: [New-bugs-announce] [issue6117] Fix O(n**2) performance problem in
	socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>


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

the socket._fileobject._wbuf is a list of strings to output.  This patch 
keeps the length of this buffer as a separate member variable, rather than  
computing it dynamically, which sums to a O(n**2) operation as the buffer 
is filled up.  Significant performance degradation was observed when 
outputting lots of small data to a buffered socket using the old method.

----------
files: socket.patch
keywords: easy, needs review, patch, patch
messages: 88366
nosy: krisvale
severity: normal
status: open
title: Fix O(n**2) performance problem in socket._fileobject
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file14080/socket.patch

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

From report at bugs.python.org  Tue May 26 18:15:24 2009
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 26 May 2009 16:15:24 +0000
Subject: [New-bugs-announce] [issue6118] urllib.parse.quote_plus ignores
	optional arguments
In-Reply-To: <1243354524.61.0.291164440748.issue6118@psf.upfronthosting.co.za>
Message-ID: <1243354524.61.0.291164440748.issue6118@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urllib.parse.quote_plus will ignore its encoding and errors arguments if
its input string has a space in it.

Intended behaviour:
>>> urllib.parse.quote_plus("\xa2\xd8 \xff", encoding='latin-1')
'%A2%D8+%FF'
Observed behaviour:
>>> urllib.parse.quote_plus("\xa2\xd8 \xff", encoding='latin-1')
'%C2%A2%C3%98+%C3%BF'
(This just uses the default UTF-8 encoding).

Attached patch with test cases. This only affects Python 3.x (the 2.x
branch has no encoding/errors argument).

----------
components: Library (Lib)
files: urllib_quote_plus.patch
keywords: patch
messages: 88368
nosy: mgiuca
severity: normal
status: open
title: urllib.parse.quote_plus ignores optional arguments
type: behavior
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14081/urllib_quote_plus.patch

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

From report at bugs.python.org  Tue May 26 23:24:01 2009
From: report at bugs.python.org (Alejandro)
Date: Tue, 26 May 2009 21:24:01 +0000
Subject: [New-bugs-announce] [issue6119] Confusing DeprecationWarning
In-Reply-To: <1243373041.06.0.391551220918.issue6119@psf.upfronthosting.co.za>
Message-ID: <1243373041.06.0.391551220918.issue6119@psf.upfronthosting.co.za>


New submission from Alejandro <alejolp at alejolp.com>:

Comparing a lambda and a built-in by equality ("==") raises a
DeprecationWarning when the "-3" flag is used on Python 2.6.2:

$ python2.6 -3
Python 2.6.2 (r262:71600, Apr 28 2009, 16:17:29) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda x: x) == eval
__main__:1: DeprecationWarning: builtin_function_or_method inequality
comparisons not supported in 3.x
False

On Python 3.0.1 it works just fine:

$ python3.0
Python 3.0.1 (r301:69556, Apr 28 2009, 19:47:09) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda x: x) == eval
False
>>>

----------
components: Interpreter Core
messages: 88394
nosy: alejolp
severity: normal
status: open
title: Confusing DeprecationWarning
versions: Python 2.6

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

From report at bugs.python.org  Wed May 27 06:19:49 2009
From: report at bugs.python.org (Wentao Han)
Date: Wed, 27 May 2009 04:19:49 +0000
Subject: [New-bugs-announce] [issue6120] zipfile.ZipFile's extractall works
	inproperly under	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>


New submission from Wentao Han <wentao.han at gmail.com>:

On Windows, if you extract all files from a zip file which containing 
subdirectories by zipfile.ZipFile's extractall method, a WindowsError will 
be raised.

----------
components: Library (Lib)
messages: 88400
nosy: aerodonkey
severity: normal
status: open
title: zipfile.ZipFile's extractall works inproperly under Windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May 27 06:57:38 2009
From: report at bugs.python.org (July)
Date: Wed, 27 May 2009 04:57:38 +0000
Subject: [New-bugs-announce] [issue6121] help('modules ') causes IndexError.
Message-ID: <1243400257.71.0.640589721505.issue6121@psf.upfronthosting.co.za>


Changes by July <july.tikh at gmail.com>:


----------
assignee: theller
components: ctypes
nosy: July, theller
severity: normal
status: open
title: help('modules ') causes IndexError.
type: behavior

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

From report at bugs.python.org  Wed May 27 10:12:16 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 08:12:16 +0000
Subject: [New-bugs-announce] [issue6122] [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>


New submission from Yonas <yonas.y at gmail.com>:

I always get a subprocess error when using embedded Python 2.6.2:

File "/usr/lib/python2.6/subprocess.py", line 1123, in wait:     pid,
sts = os.waitpid(self.pid, 0): OSError: [Errno 10] No child processes

Sample library and main files attached.

----------
files: mylib.c
messages: 88407
nosy: yonas
severity: normal
status: open
title: [Errno 10] No child processes
versions: Python 2.6
Added file: http://bugs.python.org/file14088/mylib.c

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

From report at bugs.python.org  Wed May 27 14:29:07 2009
From: report at bugs.python.org (Evan Jones)
Date: Wed, 27 May 2009 12:29:07 +0000
Subject: [New-bugs-announce] [issue6123] tarfile:
In-Reply-To: <1243427347.79.0.845990376951.issue6123@psf.upfronthosting.co.za>
Message-ID: <1243427347.79.0.845990376951.issue6123@psf.upfronthosting.co.za>


New submission from Evan Jones <evanj at mit.edu>:

tarfile.open() with an empty tar archive fails with a ReadError
exception. GNU tar refuses to create empty archives, but tarfile allows
it. See the following code which reproduces the error. I used the
version of tarfile.py from subversion (revision 72458) with Python 2.5
on Linux.

Exception:

Traceback (most recent call last):
  File "test.py", line 15, in <module>
    tar = tarfile.open(fileobj=data)
  File "/home/evanj/taskmgr/tarfile.py", line 1649, in open
    raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully

The problem seems to be that when TarFile.next() is called, it raises
the following exception for the empty tar file:

  File "/home/evanj/taskmgr/tarfile.py", line 2310, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/home/evanj/taskmgr/tarfile.py", line 1235, in fromtarfile
    obj = cls.frombuf(buf)
  File "/home/evanj/taskmgr/tarfile.py", line 1190, in frombuf
    raise HeaderError("empty header")


The attached patch works for me, but no guarantees that it doesn't cause
other problems!


Sample code:

import cStringIO
import tarfile

# Create an empty tar file
data = cStringIO.StringIO()
tar = tarfile.open(mode="w", fileobj=data)
tar.close()
print "empty tar file; length:", len(data.getvalue())

# Open the tar file
data.seek(0)
tar = tarfile.open(fileobj=data)
print tar

----------
components: Extension Modules
files: tarfile-empty.diff
keywords: patch
messages: 88416
nosy: evanj at mit.edu
severity: normal
status: open
title: tarfile:
type: behavior
Added file: http://bugs.python.org/file14093/tarfile-empty.diff

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

From report at bugs.python.org  Wed May 27 17:01:12 2009
From: report at bugs.python.org (Marc Culler)
Date: Wed, 27 May 2009 15:01:12 +0000
Subject: [New-bugs-announce] [issue6124] Tkinter should support the OS X
	zoom button
In-Reply-To: <1243436472.73.0.689907343638.issue6124@psf.upfronthosting.co.za>
Message-ID: <1243436472.73.0.689907343638.issue6124@psf.upfronthosting.co.za>


New submission from Marc Culler <culler at math.uic.edu>:

As far as I can tell, no Tkinter event or pseudo event is generated by
clicking the green "zoom" button on Mac OS X windows.  This makes it
impossible to support that OS X paradigm in a Tkinter application.

I would like to be able to bind "<<Zoom>>" to a command that resizes the
window according to the OS X UI guidelines.  By the way, the guidelines
specify that the interpretation of "zoom" depends on the application,
and the effect need not be the same as "maximize".

----------
components: Tkinter
messages: 88419
nosy: culler
severity: normal
status: open
title: Tkinter should support the OS X zoom button
type: feature request

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

From report at bugs.python.org  Wed May 27 20:53:14 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 27 May 2009 18:53:14 +0000
Subject: [New-bugs-announce] [issue6125] 2to3 mishandles "from module_name
	import" when	module_name includes an underscore
In-Reply-To: <1243450394.39.0.563669529088.issue6125@psf.upfronthosting.co.za>
Message-ID: <1243450394.39.0.563669529088.issue6125@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

2to3 -f import l.py
--- l.py (original)
File p.py (the four modules exist in the same directory as p.py):

from mod_a import a
from modb import b
from mod_c import *
from modd import *


% 2to3 -f import p.py
+++ p.py (refactored)
@@ -1,5 +1,5 @@
-from mod_a import a
-from modb import b
-from mod_c import *
-from modd import *
+from .mod_a import a
+from .modb import b
+from .mod_c import *
+from .modd import *

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 88427
nosy: MLModel
severity: normal
status: open
title: 2to3 mishandles "from module_name import" when module_name includes an underscore
versions: Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed May 27 21:15:07 2009
From: report at bugs.python.org (Eric Promislow)
Date: Wed, 27 May 2009 19:15:07 +0000
Subject: [New-bugs-announce] [issue6126] Python 3 pdb: shows internal code,
	breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

I have a simple test file, test01.py, with this output:
$ cat test01.py
#!/usr/bin/env python

print("Line 1")
print("Line 2")
print("Line 3")
$
$ # Now try debugging it.
$ python3.0 -mpdb test01.py
--Return--
> /home/ericp/opt/Python-3.0.1/lib/python3.0/io.py(762)closed()->False
-> return self.raw.closed
(Pdb) b test01.py:4
Breakpoint 1 at /home/ericp/lab/Python-3.0.1/test01.py:5
(Pdb) r
--Return--
> /home/ericp/opt/Python-3.0.1/lib/python3.0/io.py(1471)closed()->False
-> return self.buffer.closed
(Pdb) c
line 1
line 2
line 3
The program finished and will be restarted

Two main problems:

1. I shouldn't see the code for io.py

2. The program doesn't stop at the breakpoint, because that 
stack frame is exposed to bdb as (file:"<string>", line:4),
not (file:"/home/.../test01.py", line:4).

----------
components: Interpreter Core
messages: 88431
nosy: ericp
severity: normal
status: open
title: Python 3 pdb: shows internal code, breakpoints don't work
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed May 27 22:01:43 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 27 May 2009 20:01:43 +0000
Subject: [New-bugs-announce] [issue6127] Unexpected universal newline
	behavior (newline	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Per http://bugs.python.org/issue5265, I'm opening up a new ticket. 
Universal newline behavior works as expected under Linux but differently
under Windows.

PS C:\Users\jaraco> python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
>>> import io
>>> io.StringIO('foo\r\nbar\r\n', newline=None).read()
u'foo\n\nbar\n\n'

As you can see, the newlines get duplicated.

The problem doesn't seem to be with universal newline support in
general, but the StringIO implementation in particular.

PS C:\Users\jaraco\projects\formworx> python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit
(AMD64)] on win32
>>> open("testnl.txt", "wb").write("foo\r\nbar\r\n")
>>> open("testnl.txt", "rU").read()
'foo\nbar\n'

----------
components: IO
messages: 88438
nosy: jaraco
severity: normal
status: open
title: Unexpected universal newline behavior (newline duplication) in Windows
versions: Python 2.6

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

From report at bugs.python.org  Wed May 27 22:48:56 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 27 May 2009 20:48:56 +0000
Subject: [New-bugs-announce] [issue6128] Consequences of using
	Py_TPFLAGS_HAVE_GC are incompletely	explained
In-Reply-To: <1243457336.14.0.579311647458.issue6128@psf.upfronthosting.co.za>
Message-ID: <1243457336.14.0.579311647458.issue6128@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Creation of GC'd types is explained at
<http://docs.python.org/c-api/gcsupport.html>.

The docs claim that PyObject_GC_Track must be called once an object
created with PyObject_GC_New is initialized.  The docs fail to explain
what should be done if there is an error during initialization of an
object created with PyObject_GC_New.  Should PyObject_GC_Track still be
called?  Should some other API be called to free the object?

Overall, the docs are missing an explanation of the overall working of
the GC and GC APIs, so it is hard to build an understanding of the
system.  Without an understand, it's difficult to read between the lines
of the API docs, meaning they need to cover every possible case, which
they don't currently.

----------
assignee: georg.brandl
components: Documentation
messages: 88441
nosy: exarkun, georg.brandl
severity: normal
status: open
title: Consequences of using Py_TPFLAGS_HAVE_GC are incompletely explained

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

From report at bugs.python.org  Wed May 27 22:56:12 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 27 May 2009 20:56:12 +0000
Subject: [New-bugs-announce] [issue6129] 2to3 does not convert imports of
	the form 'import	sub.mod' to relative import
In-Reply-To: <1243457772.14.0.914408445212.issue6129@psf.upfronthosting.co.za>
Message-ID: <1243457772.14.0.914408445212.issue6129@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

2to3 changes "import m" to "from . import m" but it doesn't change
"import sub.s".

The directory q.py is in has a file m.py and a subdirectory sub.
The subdirectory sub has a file s.py.
File q.py contains two lines:

import m
import sub.s

% 2to3 -f q.py
--- q.py (original)
+++ q.py (refactored)
@@ -1,2 +1,2 @@
-import m
+from . import m
 import sub.s
RefactoringTool: Files that need to be modified:
RefactoringTool: q.py

----------
messages: 88444
nosy: MLModel
severity: normal
status: open
title: 2to3 does not convert imports of the form 'import sub.mod' to relative import

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

From report at bugs.python.org  Wed May 27 23:02:39 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 27 May 2009 21:02:39 +0000
Subject: [New-bugs-announce] [issue6130] There ought to be a way for
	extension types to associate	documentation with their tp_new
	or tp_init methods
In-Reply-To: <1243458159.9.0.459971457445.issue6130@psf.upfronthosting.co.za>
Message-ID: <1243458159.9.0.459971457445.issue6130@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

If an extension type supplies a tp_new or tp_init, these will be invoked
by the normal instantiation logic.  They will also be exposed as
`__new__? and `__init__? attributes of the type.  However, there is no
way to supply a docstring for these methods.  Instead, these methods get
a hard coded docstring defined in typeobject.c.

----------
components: Interpreter Core
messages: 88446
nosy: exarkun
severity: normal
status: open
title: There ought to be a way for extension types to associate documentation with their tp_new or tp_init methods

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

From report at bugs.python.org  Wed May 27 23:56:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 21:56:26 +0000
Subject: [New-bugs-announce] [issue6131] test_modulefinder leaks when run
	after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>


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

When run independently, test_modulefinder doesn't leak:

$ ./python -m test.regrtest -R 3:2 test_modulefinder
test_modulefinder
beginning 5 repetitions
12345
.....
1 test OK.
[93448 refs]

But it does leak if test_distutils was run before it:

$ ./python -m test.regrtest -R 3:2 test_distutils test_modulefinder
test_distutils
[31861 refs]
beginning 5 repetitions
12345
[31861 refs]
.[31861 refs]
.[31861 refs]
.[31861 refs]
.[31861 refs]
.
test_modulefinder
beginning 5 repetitions
12345
.....
test_modulefinder leaked [145, 145] references, sum=290


The fact that test_modulefinder uses distutils.dir_util could have
something to do with this?

----------
components: Library (Lib), Tests
messages: 88449
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: test_modulefinder leaks when run after test_distutils
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Thu May 28 00:09:55 2009
From: report at bugs.python.org (Phillip Sitbon)
Date: Wed, 27 May 2009 22:09:55 +0000
Subject: [New-bugs-announce] [issue6132] Implement the GIL with critical
	sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>


New submission from Phillip Sitbon <phillip.sitbon+python-dev at gmail.com>:

At the suggestion of others on the Python-Dev list, I'm going to outline
what I've been doing with the GIL and where I see possiblity for
improvement.

Discussion:
http://mail.python.org/pipermail/python-dev/2009-May/089746.html


Detail:

Currently, Python's global interpreter lock is implemented with the same
mechanism that provides locks for the threading module. Moving the GIL's
low-level handling to a separate mechanism would free core developers
from the feature requirements imposed upon thread locks, specifically:

1. Blocking recursion

A thread can acquire a lock when it has already been acquired, and this
action will block.

2. Release-anywhere

Any thread not owning a lock can release it (provided it is currently
owned), thus preventing permanent deadlock in #1.

These semantics are that of a semaphore with an initial value of 1,
where acquisitions decrease its value and releases increment its value.
This behavior cannot change without changing the fundamental behavior of
the threading.Lock object that many have probably come to expect.

I have been looking into ways to minimize GIL overhead in high
concurrency situations. At the moment, I'm only looking at Windows,
partly because it was an easy target and I have experience with its
synchronization objects. While I have come up with a faster alternative
for GIL handling, it breaks the expectations of thread lock objects. I
then got to wondering:

- Does anyone actually use the GIL-locking/unlocking functions in a
manner that requires the features listed above?

- If so, could it be accomplished a different way if the GIL were
expected to behave more like a recursive mutex?

I'm not going to make any assumptions about what extensions do with the
GIL, but I can hope at least they do use the API functions. If so, the
question is if we can safely apply different locking semantics to the GIL:

- Non-blocking recursion

A thread that already owns the lock can re-acquire it without blocking,
increasing a recursion count.

- Owner-only releasing

Only the thread owning the lock can release it, and only as many times
as it has acquired it.

In Windows, this is how critical sections behave. I'm not sure about the
Linux futex, but I know pthread mutexes and others like it can be made
recursive. I'm mainly interested in separating the GIL from thread locks
so we can say "do x and y with it but not z" without changing the
threading module's lock mechanism.

I decided to make a case of this when I was testing my ISAPI extension
under high load. The current mechanism is as fast as it can possibly be
for a single thread, but does not scale well at all. This has a lot to
do with its use of event synchronization objects. Critical sections, on
the other hand, scale well even when contention is unavoidable. My first
experiment involved modifying the thread lock functions in thread_nt.h
to use critical sections. Yes, it broke the behavior of threading.Lock,
but it still worked for the GIL. The performance improvement can vary,
but it's always noticeable in the presence of concurrency. I saw the
performance of my server extension nearly double when serving up Django
pages from 10-12 threads concurrently.

Obviously we can't just slap on a critical section and call it done,
unless nobody cares about changing what threading.Lock does. That's what
led me believe that a separate GIL mechanism is very important to have.

For your hacking pleasure, I've included a patch for thread_nt.h that
will facilitate GIL performance testing. It includes the critical
section implementation and a semaphore implementation (which is about as
fast as the current behavior). I've also included a _very_ basic script
for some ballpark GIL contention measurements. The numbers will be a bit
exaggerated, especially with a _Py_CheckInterval of 1, but you will see
the difference between the current method and the critical section
method right away. Especially in terms of scalability.

If you want a baseline cost for the iteration loops, change ThreadCount
to 1 and make CheckInterval something big (>1 million). There are other
costs included with the reported numbers, but going between the two lock
implementations should make it clear that any big difference you see is
due to locking/unlocking/contention. Please feel free to correct me if I
did it all wrong - I'm sure there are other/better ways to test GIL
performance.

My testing was done with Python 2.6.2 x86 on Vista x64. I can provide
measurements if it's not convenient for anyone to try out the patch.

So where to go from here?

It'd be good to know if changing the restrictions on GIL usage will
break anything. Also, whether the same performance increase can be had
for Linux/Mac/others.

I'll continue to look into giving the GIL its own locking API, and
hopefully my efforts are not for naught.

----------
components: Interpreter Core, Windows
files: thread_nt.h.patch
keywords: patch
messages: 88452
nosy: sitbon
severity: normal
status: open
title: Implement the GIL with critical sections in Windows
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14096/thread_nt.h.patch

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

From report at bugs.python.org  Thu May 28 01:19:51 2009
From: report at bugs.python.org (Alex)
Date: Wed, 27 May 2009 23:19:51 +0000
Subject: [New-bugs-announce] [issue6133] LOAD_CONST followed by LOAD_ATTR
	can be optimized to just	be a LOAD_COST
In-Reply-To: <1243466391.88.0.68447044966.issue6133@psf.upfronthosting.co.za>
Message-ID: <1243466391.88.0.68447044966.issue6133@psf.upfronthosting.co.za>


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

Basically whenever you have a LOAD_CONST opcode, follwed by a LOAD_ATTR
you can replace both with a single LOAD_CONST.  This optimizes things
like ", ".join or "{} {}".format (in my totally unscientific byte code
hackery it's about a 30% speedup on the loading the function).  This can
be done in the peephole optimizer.

I'll try to work up a patch.

----------
components: Interpreter Core
messages: 88455
nosy: alex
severity: normal
status: open
title: LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

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

From report at bugs.python.org  Thu May 28 07:05:10 2009
From: report at bugs.python.org (James Abbatiello)
Date: Thu, 28 May 2009 05:05:10 +0000
Subject: [New-bugs-announce] [issue6134] 2to3 tests fail on Windows due to
	line endings
In-Reply-To: <1243487110.56.0.988567820731.issue6134@psf.upfronthosting.co.za>
Message-ID: <1243487110.56.0.988567820731.issue6134@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

The tests for 2to3 currently fail on Windows.  Data is read from a file
in binary mode and then written to a temporary file in text mode which
doubles up the carriage returns.

Additionally, several files are missing the svn:eol-style property.  The
attached patch addresses both problems.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_native_eol.patch
keywords: patch
messages: 88464
nosy: abbeyj
severity: normal
status: open
title: 2to3 tests fail on Windows due to line endings
Added file: http://bugs.python.org/file14102/2to3_native_eol.patch

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

From report at bugs.python.org  Thu May 28 09:08:44 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 28 May 2009 07:08:44 +0000
Subject: [New-bugs-announce] [issue6135] subprocess seems to use local 8-bit
	encoding and gives no	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

When I start a process with subprocess.Popen() and pipe the stdin and
stdout, it always seems to use the local 8-bit encoding.

I tried setting process.stdin.encoding = "utf8" and the same for stdout
(where process is the subprocess object), but to no avail.

I also tried using shell=True since on Mac, Terminal.app is fine with
Unicode, but that didn't work.

So basically, I have programs that output Unicode and run fine on the
Mac terminal, but that cannot be executed by subprocess because
subprocess uses the mac_roman encoding instead of Unicode.

I wish it were possible to specify the stdin and stdout encoding that is
used; then I could use the same one on all platforms. (But perhaps it is
possible, and I just haven't figured out how?)

----------
components: Library (Lib)
messages: 88466
nosy: mark
severity: normal
status: open
title: subprocess seems to use local 8-bit encoding and gives no choice
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu May 28 09:09:59 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 28 May 2009 07:09:59 +0000
Subject: [New-bugs-announce] [issue6136] Make logging configuration files
	easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

Recently tried to use the logging configuration file format as
understood by logging.config.fileConfig() and found it very unwieldy for
normal usage. I feel it needs to "scale down" better. Some thoughts:

a) It creates handlers whether they're needed or not. This means you
cannot leave the handler sections present in your configuration file and
just disable and enable the logger by changing the level, or your
application will open the files/sockets etc. anyway, whether the loggers
are enabled or not. This is bordering on being a bug rather than just an
annoyance...

b) There is a lot of unnecessary cruft. For example it should be
possible to eliminate the [loggers], [handlers] and [formatters]
sections. I gather they're there due to a limitation of ConfigParser but
I assume this is historical as I can see no good reason for it now.
Also, entries should default sensibly, e.g. "qualname" should not be
treated as vital but should default to the name in the section header.

c) I'd also suggest providing a newer, non-back-compatible format
alongside the existing one that was less wordy for normal use. Get rid
of the separate "handlers" and "formatters" and make each logger have a
section of its own containing all "handling" and "formatting"
information: most users aren't going to want to think about these things
as separate entities and in any case there is the hierarchical mechanism
to prevent too much copying.

In fact, I'd suggest extending the "basicConfig" idea to be able to call
it on individual loggers, and build a new format around that, where each
section is read and a logger created with the contents passed as keyword
arguments to "basicConfig".

I might have time to do some of this myself but I want to be sure people
think it's a good idea before investing time in it.

----------
components: Extension Modules
messages: 88467
nosy: gjb1002
severity: normal
status: open
title: Make logging configuration files easier to use
type: feature request

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

From report at bugs.python.org  Thu May 28 10:52:37 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Thu, 28 May 2009 08:52:37 +0000
Subject: [New-bugs-announce] [issue6137] Pickle migration: Should pickle map
	"copy_reg" to	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>


New submission from Matthias Kievernagel <mkiever at web.de>:

Hello,

while porting something to Python 3.1a1
I found out that Python 3 cannot load most Python 2 pickles
of any protocol because copy_reg has been renamed to copyreg.

Found this comment by Skip Montanaro in related issue:
  http://bugs.python.org/issue3799#msg76196

Could not find an issue opened for this though.
So I'm opening one.

Regards,
Matthias Kievernagel

----------
components: None
messages: 88470
nosy: mkiever
severity: normal
status: open
title: Pickle migration: Should pickle map "copy_reg" to "copyreg"?
versions: Python 3.1

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

From report at bugs.python.org  Thu May 28 23:01:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 21:01:55 +0000
Subject: [New-bugs-announce] [issue6138] ./configure;
	make install fails in setup.py step
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

With current trunk, after a make distclean; ./configure; make install
sequence, I get the following error:

[...]
# Substitution happens here, as the completely-expanded BINDIR
# is not available in configure
sed -e "s, at EXENAME@,/usr/local/bin/python2.7," < ./Misc/python-config.in
>python-config
/usr/bin/install -c python-config /usr/local/bin/python2.7-config
rm python-config
./python -E ./setup.py install \
                --prefix=/usr/local \
                --install-scripts=/usr/local/bin \
                --install-platlib=/usr/local/lib/python2.7/lib-dynload \
                --root=/
running install
error: must supply either home or prefix/exec-prefix -- not both
make: *** [sharedinstall] Error 1

----------
messages: 88476
nosy: r.david.murray, tarek
priority: release blocker
severity: normal
status: open
title: ./configure; make install fails in setup.py step
type: compile error
versions: Python 2.7, Python 3.1

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

From martin at v.loewis.de  Thu May 28 23:44:18 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 28 May 2009 23:44:18 +0200
Subject: [New-bugs-announce] [issue6132] Implement the GIL with critical
 sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
References: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <4A1F05B2.1010203@v.loewis.de>

> Obviously we can't just slap on a critical section and call it done,
> unless nobody cares about changing what threading.Lock does.

This isn't obvious to me. I do care about what threading.Lock does,
but still fail to see why we can't just slap on a criticial section
and call it done.

From report at bugs.python.org  Fri May 29 01:56:03 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 28 May 2009 23:56:03 +0000
Subject: [New-bugs-announce] [issue6139] Typo in email.base64mime
In-Reply-To: <1243554963.67.0.192911044449.issue6139@psf.upfronthosting.co.za>
Message-ID: <1243554963.67.0.192911044449.issue6139@psf.upfronthosting.co.za>


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

I think I found typo in Lib/email/base64mime.py

----------
files: fix_typo.patch
keywords: patch
messages: 88489
nosy: ocean-city
severity: normal
status: open
title: Typo in email.base64mime
versions: Python 3.1
Added file: http://bugs.python.org/file14107/fix_typo.patch

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

From report at bugs.python.org  Fri May 29 03:20:59 2009
From: report at bugs.python.org (Sashi)
Date: Fri, 29 May 2009 01:20:59 +0000
Subject: [New-bugs-announce] [issue6140] configure error: shadow.h: present
	but cannot be compiled
In-Reply-To: <1243560059.83.0.307213103103.issue6140@psf.upfronthosting.co.za>
Message-ID: <1243560059.83.0.307213103103.issue6140@psf.upfronthosting.co.za>


New submission from Sashi <sashi at voltage.com>:

Got the following error while building Python 2.5.2 on HP-UX 11.11

bash-3.2$ uname -a
HP-UX hpux B.11.11 U 9000/785 2010988722 unlimited-user license

configure: WARNING:

  By default, distutils will build C++ extension modules with "g++".
  If this is not intended, then set CXX on the configure command line.

configure: WARNING: shadow.h: present but cannot be compiled
configure: WARNING: shadow.h:     check for missing prerequisite headers?
configure: WARNING: shadow.h: see the Autoconf documentation
configure: WARNING: shadow.h:     section "Present But Cannot Be Compiled"
configure: WARNING: shadow.h: proceeding with the preprocessor's result
configure: WARNING: shadow.h: in the future, the compiler will take
precedence
configure: WARNING:     ##
------------------------------------------------ ##
configure: WARNING:     ## Report this to
http://www.python.org/python-bugs ##
configure: WARNING:     ##
------------------------------------------------ ##
creating Modules/Setup
creating Modules/Setup.local
creating Makefile

----------
components: Build
messages: 88491
nosy: Sashi
severity: normal
status: open
title: configure error: shadow.h: present but cannot be compiled
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Fri May 29 12:06:50 2009
From: report at bugs.python.org (Lie Ryan)
Date: Fri, 29 May 2009 10:06:50 +0000
Subject: [New-bugs-announce] [issue6141] missing first argument on
	subprocess.Popen w/ executable
In-Reply-To: <1243591610.71.0.101419650032.issue6141@psf.upfronthosting.co.za>
Message-ID: <1243591610.71.0.101419650032.issue6141@psf.upfronthosting.co.za>


New submission from Lie Ryan <lie.1296 at gmail.com>:

Following from http://comments.gmane.org/gmane.comp.python.tutor/55576

>>> import subprocess
>>> subprocess.Popen(['a', 'b', 'c', 'd'], executable='echo')
<subprocess.Popen object at 0x7fdf7bb2bd50>
b c d

instead of the (what I) expected result
a b c d

I suggests two possible change:
1. add another optional argument called displayed_executable (or
something similar) and make the arg argument contains only arguments
2. it is made clear in the documentation that the first argument is used
as executable display name

Since the first alternative is behavioral change, it couldn't possibly
go through already released version; therefore if it is the chosen
solution it would have to go to Python 2.7 and Python 3.2. 

Changing the documentation should be easier, although the problem will
persist for unsuspecting users; and even if the first alternative is
taken, perhaps documentation change should still be done retrospectively
(I don't know the policy on doc change on old python version)

It should be noted that I tested this only with Python 2.5 on Gentoo
(although from the discussion, I presumed this is considered a feature
and would have persisted in later versions). And at the time of this
writing, I have no idea how it behaves in Windows.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 88504
nosy: georg.brandl, lieryan
severity: normal
status: open
title: missing first argument on subprocess.Popen w/ executable
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May 29 17:51:11 2009
From: report at bugs.python.org (James)
Date: Fri, 29 May 2009 15:51:11 +0000
Subject: [New-bugs-announce] [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Priority: 4
Keywords: patch, distutils, pyc
Comment:
I posted this on the distutils mailing list, and they said I should post
it here instead.

---
Hi,
I'm certaintly new to distutils and setuptools, however I figured I'd
send in this patch, and either it will get merged because it's a great
idea or someone will perhaps tell me why this doesn't exist already.
(or maybe it does and i can't find it)
In any case, it adds the pyc option to the clean command so that the
.pyc can be removed on request. Personally i'll have a [clean] pyc=1
option in my setup.cfg, but that's for my convenience.
cheers,

_J


---

ps: i wasn't able to pick a priority or keywords, there isn't a box to
type those in, however the titles are there. so either i don't have
permissions or there's a bug ?

----------
files: clean.py.patch
keywords: patch
messages: 88512
nosy: purpleidea
severity: normal
status: open
title: Distutils doesn't remove .pyc files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14112/clean.py.patch

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

From report at bugs.python.org  Fri May 29 23:09:51 2009
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 29 May 2009 21:09:51 +0000
Subject: [New-bugs-announce] [issue6143] IDLE - an extension to clear the
	shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

I noticed that the feature to clear the shell window has been a
discussion topic in the IDLE-dev archives for a few years. Here's an
extension that can clear the contents of the shell window. It provides
"Clear Shell Window" under "Options" and a <Ctrl-L> key binding.

The source code provides two methods to do this. The
ModifiedUndoDelegator prevents changing the contents of the text widget
before "iomark". One solution is to disable the filter, make the
changes, then re-enable it. Another solution is move "iomark" to the
beginning of the document. Any thoughts?

----------
components: IDLE
files: ClearWindow.py
messages: 88539
nosy: serwy
severity: normal
status: open
title: IDLE - an extension to clear the shell window
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14116/ClearWindow.py

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

From report at bugs.python.org  Fri May 29 23:11:12 2009
From: report at bugs.python.org (jamesie)
Date: Fri, 29 May 2009 21:11:12 +0000
Subject: [New-bugs-announce] [issue6144] [IDLE] UnicodeDecodeError when
	invoking	force-open-completions
In-Reply-To: <1243631472.83.0.652127430893.issue6144@psf.upfronthosting.co.za>
Message-ID: <1243631472.83.0.652127430893.issue6144@psf.upfronthosting.co.za>


New submission from jamesie <post06 at jamesie.de>:

IDLE 3.1b1 crashes when I press Control-SPACE in order to invoke Show
Completions from the Edit submenu. When I run that funtionality from the
menu it works ok.

Traceback (most recent call last):
  File "/usr/local/bin/idle3", line 5, in <module>
    main()
  File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 1009, in
mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
illegal encoding

I rund a hand-compiled Python 3.1b1 on Debian/GNU Linux Lenny.

----------
components: IDLE
messages: 88540
nosy: gpolo, jamesie
severity: normal
status: open
title: [IDLE] UnicodeDecodeError when invoking force-open-completions
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat May 30 00:07:02 2009
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 29 May 2009 22:07:02 +0000
Subject: [New-bugs-announce] [issue6145] distutils.extension.read_setup_file
	misinterprets -C	switch
In-Reply-To: <1243634822.12.0.843073903173.issue6145@psf.upfronthosting.co.za>
Message-ID: <1243634822.12.0.843073903173.issue6145@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

I'm not sure if this is a bug or some weird backward-compatible behaviour...

In "distutil.extension.read_setup_file" it checks for the "-C" switch
but then appends "word" instead of "value"
So if you pass "-C-Wall" it actually passes exactly that to the compiler
instead of just "-Wall"

In the file it says the switch is "only here 'cause makesetup has it!"
so is this some behaviour the way it is for compability reasons or am I
missing something?

If this is indeed a bug I attached a patch

----------
assignee: tarek
components: Distutils
files: distutil_extension.patch
keywords: patch
messages: 88542
nosy: donlorenzo, tarek
severity: normal
status: open
title: distutils.extension.read_setup_file misinterprets -C switch
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14117/distutil_extension.patch

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

From report at bugs.python.org  Sat May 30 01:20:57 2009
From: report at bugs.python.org (Trundle)
Date: Fri, 29 May 2009 23:20:57 +0000
Subject: [New-bugs-announce] [issue6146] markup error in
	Doc/library/rlcompleter.rst
In-Reply-To: <1243639257.69.0.988766208068.issue6146@psf.upfronthosting.co.za>
Message-ID: <1243639257.69.0.988766208068.issue6146@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

There is a small markup error in the description of Completer objects.
The attached patch fixes this.

----------
assignee: georg.brandl
components: Documentation
files: rlcompleter_doc_markup.patch
keywords: patch
messages: 88551
nosy: Trundle, georg.brandl
severity: normal
status: open
title: markup error in Doc/library/rlcompleter.rst
versions: Python 2.7
Added file: http://bugs.python.org/file14118/rlcompleter_doc_markup.patch

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

From report at bugs.python.org  Sat May 30 02:04:48 2009
From: report at bugs.python.org (Alex James)
Date: Sat, 30 May 2009 00:04:48 +0000
Subject: [New-bugs-announce] [issue6147] multithreading.Pool.map() crashes
	Windows computer
In-Reply-To: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>
Message-ID: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>


New submission from Alex James <ac.james at shaw.ca>:

When calling multithreading.Pool().map() to distribute computational
load I've recently got system crashes.  

The attached minimalist script exhibits this issue.  
On a Windows Vista home premium sp1 running Python 2.6.2 on a dual-core
laptop, the script stops executing at
threading.Condition(threading.Lock()).wait() called from
multithreading.ApplyResult().wait() called from
multithreading.ApplyResult().get() called from
multithreading.Pool().map() and then compiles the original script as it
starts the script form the beggining twice simultaneously.  The printed
output gets mixed content and both new instances of the script hit the
same problem and spawn more instances.  All old processes are still
active in memory so this leads to system resources being fully consumed.  

This behavior started occurring recently, immediately after attempting
to install a Python .Egg package.  I have uninstalled python an all
extensions, restarted windows, deleted all orphan files and registry
keys I could find, restarted windows, and then re-installed a fresh
download of 2.6.2, but the problem remains.  

The error output retrievable from Keyboard Interrupt (which only works
when script was started on commandline) contains several copies of """
Traceback:
file "<string>", line 1, in <module>
'import site' failed: use -v for traceback
script opening print statement
script opening print statement
'import site' failed: use -v for traceback
File "C:\Python26\lib\multiprocessing\forking.py", line 341, in main
prepare(preparation_data)
File "C:\Python26\lib\multiprocessing\forking.py", line 456, in prepare
'__parents_main__', file, path_name, etc
File "H:\builder26\test_a6.py", line 1, in <module>
Traceback:
from custom_module import *
"""
amoung many pieces thereof stuffed bytewise into other pieces thereof.  

Identical code running in Unix operates just fine, and the identical
code worked on my machine last week.  Reproducability of this error is
thus doubtful.  Repeatability is perfect however.  

Any possible workarounds and/or understanding of root cause is
appreciated for this very rare extreme error.

----------
components: Windows
files: test_a10.py
messages: 88557
nosy: ac.james
severity: normal
status: open
title: multithreading.Pool.map() crashes Windows computer
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file14119/test_a10.py

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

From report at bugs.python.org  Sat May 30 08:37:21 2009
From: report at bugs.python.org (Ian Miers)
Date: Sat, 30 May 2009 06:37:21 +0000
Subject: [New-bugs-announce] [issue6148] Help well execute code it is called
	on
In-Reply-To: <1243665441.27.0.193785694569.issue6148@psf.upfronthosting.co.za>
Message-ID: <1243665441.27.0.193785694569.issue6148@psf.upfronthosting.co.za>


New submission from Ian Miers <imichaelmiers at gmail.com>:

when calling help() from the python interpreter on a function 
whose default argument is provided by another function 
( e.g. def foo(bar=baz() ) : .... ), help will call baz().

This can cause problems because baz() can alter statefull
data  like a file or database entry. 

This is both a bug in that it does this and in that
its undocumented 

To see this download the attached file and then : 
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bug
>>> help(bug)

at this point the file bug now has been written to disk. 
This is a problem

I've got to think there is a reason for this, but seeing as I cant 
come up with it , better safe than sorry.

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: bug.py
messages: 88565
nosy: georg.brandl, imiers1
severity: normal
status: open
title: Help well execute code it is called on
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14120/bug.py

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

From report at bugs.python.org  Sat May 30 22:07:44 2009
From: report at bugs.python.org (mike bayer)
Date: Sat, 30 May 2009 20:07:44 +0000
Subject: [New-bugs-announce] [issue6149] WeakValueDictionary constructor
	ported to Python 3.0	incorrectly
In-Reply-To: <1243714064.27.0.0793186526424.issue6149@psf.upfronthosting.co.za>
Message-ID: <1243714064.27.0.0793186526424.issue6149@psf.upfronthosting.co.za>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

The constructor for WeakValueDictionary does not obey the contract
documented in its comments:

    # We inherit the constructor without worrying about the input
    # dictionary; since it uses our .update() method, we get the right
    # checks 

yet it initializes with:

   self.data = d = {}
   d.update(*args, **kw)

i.e. the "update()" method of dict, so that a dict passed to the
constructor initializes non-weakrefed values in the dict which is
completely invalid state.

Contrast to that of 2.6, which properly uses the superclass:

UserDict.UserDict.__init__(self, *args, **kw)

A simple test which raises an exception on 3.0.1 is as follows:

import weakref

class Foo(object):
    pass
    
mydict = dict((k, Foo()) for k in range(10))

w = weakref.WeakValueDictionary(mydict)

assert w[5]

----------
messages: 88577
nosy: zzzeek
severity: normal
status: open
title: WeakValueDictionary constructor ported to Python 3.0 incorrectly
versions: Python 3.0

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

From report at bugs.python.org  Sat May 30 22:45:02 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 30 May 2009 20:45:02 +0000
Subject: [New-bugs-announce] [issue6150] test_unicode fails in wide unicode
	build
In-Reply-To: <1243716302.52.0.46548419038.issue6150@psf.upfronthosting.co.za>
Message-ID: <1243716302.52.0.46548419038.issue6150@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

ERROR: test_codecs_utf8 (__main__.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_unicode.py", line 911, in test_codecs_utf8
    self.assertEqual('\ud800\udc02'.encode('utf-8'), b'\xf0\x90\x80\x82')
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in
position 0: surrogates not allowed

----------
components: Tests
messages: 88579
nosy: hagen
severity: normal
status: open
title: test_unicode fails in wide unicode build
versions: Python 3.1

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

From report at bugs.python.org  Sun May 31 01:25:45 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 30 May 2009 23:25:45 +0000
Subject: [New-bugs-announce] [issue6151] Make PyDescr_COMMON conform to
	standard C
In-Reply-To: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>
Message-ID: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

PyDescrObject make use of the some undefined behavior noted in PEP 3123
for PyObject in Python 2.x. Although fixing this requires breaking
backward-compatibility, this shouldn't be much a problem since
PyDescrObject is only used directly by Python itself.

----------
components: Interpreter Core
files: strict-aliasing-pydescr.diff
keywords: needs review, patch, patch
messages: 88588
nosy: alexandre.vassalotti, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Make PyDescr_COMMON conform to standard C
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14123/strict-aliasing-pydescr.diff

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

From report at bugs.python.org  Sun May 31 03:11:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 01:11:48 +0000
Subject: [New-bugs-announce] [issue6152] Parellel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>


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

This experimental patch introduces a new option to run regression tests
in parallel. The option is named '-j' by analogy with the corresponding
`make` option.

For example, to run up to two tests in parallel:
./python -m test.regrtest -j2

----------
components: Tests
files: regrtest.patch
keywords: patch
messages: 88591
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Parellel regression testing
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14125/regrtest.patch

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

From report at bugs.python.org  Sun May 31 07:14:45 2009
From: report at bugs.python.org (Winston Ewert)
Date: Sun, 31 May 2009 05:14:45 +0000
Subject: [New-bugs-announce] [issue6153] email parsing - Rare Failure
In-Reply-To: <1243746885.91.0.189696323445.issue6153@psf.upfronthosting.co.za>
Message-ID: <1243746885.91.0.189696323445.issue6153@psf.upfronthosting.co.za>


New submission from Winston Ewert <winstonewert at gmail.com>:

I was using email.message_from_string which eventually feeds block of
8192 bytes into the actual e-mail parsing code. However, in my case one
the blocks split the \r\n at the end of a submessage. This caused the
code to identify it as two newlines and thus the submessage headers were
interpreted as being content.

For my purposes I've changed:
NLCRE_crack = re.compile('(\r\n|\r|\n)')
to
NLCRE_crack = re.compile('(\r\n)')

Which prevents the problem.

I suspect that is not a good fix but I do not know the standard well
enough to know what would be a good fix.

----------
components: Library (Lib)
messages: 88593
nosy: WinstonEwert
severity: normal
status: open
title: email parsing - Rare Failure
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May 31 09:34:20 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 May 2009 07:34:20 +0000
Subject: [New-bugs-announce] [issue6154] Python 3.1 rc1 will not build on OS
	X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

I believe r72863 broke building on OS X. If you uncomment the ``-lintl``
part for _localemodule.c in Modules/Setup then Python 3.1 builds. Below
is the linkage error that Tarek and I both independently ran into.

gcc -L/Users/brett/usr/lib -L/Users/brett/.local/lib -L/unix/lib
-L/unix/macports/lib -L/Developer/usr/lib -framework CoreFoundation -o
python.exe \
			Modules/python.o \
			libpython3.1.a -ldl      
Undefined symbols:
  "_libintl_textdomain", referenced from:
      _PyIntl_textdomain in libpython3.1.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
      _PyIntl_dgettext in libpython3.1.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
      _PyIntl_dcgettext in libpython3.1.a(_localemodule.o)
  "_libintl_bindtextdomain", referenced from:
      _PyIntl_bindtextdomain in libpython3.1.a(_localemodule.o)
  "_libintl_gettext", referenced from:
      _PyIntl_gettext in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1

----------
assignee: benjamin.peterson
components: Build
messages: 88594
nosy: benjamin.peterson, brett.cannon, tarek
priority: release blocker
severity: normal
status: open
title: Python 3.1 rc1 will not build on OS X 10.5.7
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun May 31 18:20:39 2009
From: report at bugs.python.org (Michael Newman)
Date: Sun, 31 May 2009 16:20:39 +0000
Subject: [New-bugs-announce] [issue6155] "logging" example uses unavailable
	cPickle module
In-Reply-To: <1243786839.04.0.100473713969.issue6155@psf.upfronthosting.co.za>
Message-ID: <1243786839.04.0.100473713969.issue6155@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

The server portion of the example at:
"15.6.9. Sending and receiving logging events across a network"
http://docs.python.org/3.0/library/logging.html
uses "import cPickle" which is not available for Python 3.0.1

Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cPickle
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named cPickle

Alternatively, I tried to run the example from a script:
G:\Programming\python3\module_logging\SocketHandler_example>server.py
Traceback (most recent call last):
  File
"G:\Programming\python3\module_logging\SocketHandler_example\server.py",
line 4, in <module>
    import cPickle
ImportError: No module named cPickle

I fixed it by changing:
"import cPickle" to "import pickle"
and
"return cPickle.loads(data)" to "return pickle.loads(data)"

----------
assignee: georg.brandl
components: Documentation
messages: 88599
nosy: georg.brandl, mnewman
severity: normal
status: open
title: "logging" example uses unavailable cPickle module
versions: Python 3.0

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

From report at bugs.python.org  Sun May 31 18:26:02 2009
From: report at bugs.python.org (Daniel Eloff)
Date: Sun, 31 May 2009 16:26:02 +0000
Subject: [New-bugs-announce] [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>


New submission from Daniel Eloff <dan.eloff at gmail.com>:

This works:

r'([xy])(?:\1)+'

This won't compile, "error: nothing to repeat"

r'([xy])(?:\s*\1)+'

I can execute this under other regex engines, and it seems to me that it
really should work.

----------
components: Library (Lib)
messages: 88600
nosy: Eloff
severity: normal
status: open
title: Error compiling valid regex
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May 31 22:06:13 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 31 May 2009 20:06:13 +0000
Subject: [New-bugs-announce] [issue6157] Tkinter.Text: changes for bbox,
	debug, and edit methods.
In-Reply-To: <1243800373.79.0.587066766962.issue6157@psf.upfronthosting.co.za>
Message-ID: <1243800373.79.0.587066766962.issue6157@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Hi,

While testing Tkinter.Text I've found some problems and it would be good
to fix them in trunk.

The methods edit_redo, edit_reset, edit_separator and edit_undo doesn't
return anything, so I would suggest to remove the return statements there.
The debug method doesn't return a boolean when we set a value for the
debug option, so the getboolean function fails:

>>> import Tkinter
>>> text = Tkinter.Text()
>>> text.debug()
False
>>> text.debug(1)
...
_tkinter.TclError: expected boolean value but got ""


I'm also suggesting a change in the bbox signature. Right now it
supports receiving multiple args, but the bbox command in Tcl expects a
single item as the index. I believe it makes more sense to indicate that
it accepts a single argument. An index like '1.0 +1c' needs to either be
passed as '1.0 +1c' or ('1.0', '+1c') (a tuple holding the two parts),
not as '1.0', '+1c' (two arguments).

----------
components: Tkinter
files: tkinter_text_changes.diff
keywords: patch
messages: 88607
nosy: gpolo
severity: normal
status: open
title: Tkinter.Text: changes for bbox, debug, and edit methods.
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14129/tkinter_text_changes.diff

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