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: [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 00:44:33 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 30 Apr 2009 22:44:33 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1241131473.75.0.245241483562.issue5872@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Fri May  1 02:33:26 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 01 May 2009 00:33:26 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241138006.17.0.854390578884.issue5799@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The doc patch doesn't apply cleanly for me.

There are a number of code cleanups in the patch, like 0->False,
1->True, the improvement of the params to path(), improvement in
isabs(), etc. I think these cleanups should be made in a separate patch,
so that it's easier to evaluate what's really involved in this change.
I'd be happy to do that, and produce the patches, if you could produce a
clean patch.

The docstring for splitdrive() should be indented, see PEP 257. Also,
the code snippet in that docstring is wrong, it uses 'split' where it
should be 'result', I think.

I haven't worked my way through all of the code and tests, yet.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Fri May  1 06:51:08 2009
From: report at bugs.python.org (David Stemmer)
Date: Fri, 01 May 2009 04:51:08 +0000
Subject: [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: [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 06:53:55 2009
From: report at bugs.python.org (David Stemmer)
Date: Fri, 01 May 2009 04:53:55 +0000
Subject: [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: <1241153634.01.0.0344856369384.issue5891@psf.upfronthosting.co.za>


Changes by David Stemmer <dstemmer at brandeis.edu>:


Removed 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:56:04 2009
From: report at bugs.python.org (David Stemmer)
Date: Fri, 01 May 2009 04:56:04 +0000
Subject: [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: <1241153764.47.0.639402170441.issue5891@psf.upfronthosting.co.za>


David Stemmer <dstemmer at brandeis.edu> added the comment:

EDIT: delete this, duplicate post

----------

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

From report at bugs.python.org  Fri May  1 08:03:40 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 01 May 2009 06:03:40 +0000
Subject: [issue1648102] proxy_bypass in urllib handling of <local> macro
Message-ID: <1241157820.69.0.180726950513.issue1648102@psf.upfronthosting.co.za>


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

I have fix this issue, in the revision 72155 for py2.7 and revision
72156 for py3k. 
Unfortunately, we have no tests for any proxy handling condition for
Windows and Darwin. This is a very specific case in the proxy handling;
thought let the fix be in (as per the MSDN spec), unittest coverage can
dealt separately.

----------
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 08:28:45 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 06:28:45 +0000
Subject: [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: <1241159325.72.0.713491760146.issue5891@psf.upfronthosting.co.za>


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


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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 08:31:54 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 06:31:54 +0000
Subject: [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: <1241159514.69.0.855974786759.issue5892@psf.upfronthosting.co.za>


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

That is not a bug in Python. The import statement merely adds a
reference to the list into your module, so both variables point to the
very same list (my_module.some_list is other_module.some_list).
Therefore, any changes made to the list through my_module will also
affect the list as seen from other_module.

Closing the report as invalid.

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

_______________________________________
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: [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: [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 10:06:40 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 May 2009 08:06:40 +0000
Subject: [issue5883] detach() implementation
In-Reply-To: <1241043589.42.0.224421532781.issue5883@psf.upfronthosting.co.za>
Message-ID: <1241165200.77.0.779938949951.issue5883@psf.upfronthosting.co.za>


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

The various structures now contain several 'boolean' flags. It would 
improve memory usage to use bitfields. Or would this impact performance 
?

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

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

From report at bugs.python.org  Fri May  1 10:34:22 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 01 May 2009 08:34:22 +0000
Subject: [issue5887] mmap.write_byte out of bounds - no error,
	position gets screwed up
In-Reply-To: <1241116100.06.0.276322653454.issue5887@psf.upfronthosting.co.za>
Message-ID: <1241166862.11.0.417993935759.issue5887@psf.upfronthosting.co.za>


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

Can you try this with Python2.6.2? I believe this bug got fixed.

----------
nosy: +ocean-city

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 10:38:18 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 08:38:18 +0000
Subject: [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: <1241167098.49.0.475657462887.issue5894@psf.upfronthosting.co.za>


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

I think the pycountry module might be helpful:

http://pypi.python.org/pypi/pycountry

As it is at version 0.11, I think it is very far away of being ready for
inclusion in the standard library. If this doesn't quite do what you
want, please cooperate with the author of the module to make it fit your
needs.

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

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

From report at bugs.python.org  Fri May  1 10:52:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 May 2009 08:52:41 +0000
Subject: [issue5889] Extra comma in enum - fails on AIX
In-Reply-To: <1241117078.61.0.563622380824.issue5889@psf.upfronthosting.co.za>
Message-ID: <1241167961.24.0.145444637259.issue5889@psf.upfronthosting.co.za>


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

The comma isn't required, but it's good practice in Python to end lists
with a comma (so that you don't forget adding it when adding new items),
and this habit probably made it into C code there.

Fixed in r72159.

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

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

From report at bugs.python.org  Fri May  1 11:12:06 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 01 May 2009 09:12:06 +0000
Subject: [issue5714] CGIHTTPServer._url_collapse_path_split should live
	elsewhere
In-Reply-To: <1239063845.81.0.120232947257.issue5714@psf.upfronthosting.co.za>
Message-ID: <1241169126.17.0.441359435305.issue5714@psf.upfronthosting.co.za>


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

Yes, the parsing best be done in urlparse.

As this function claims to do step 6 of RFC2396, I am surprised why it
cannot be done by using existing urlparse functions itself.(Because, the
tests for RFC2396 compliance covers those cases too).

----------
nosy: +orsenthil

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 11:13:54 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 09:13:54 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241169234.78.0.525050542105.issue3672@psf.upfronthosting.co.za>


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

Here is a patch that implements this proposed approach. It introduces a
"surrogates" error handler, useful only for the utf-8 codec.

If this is accepted, the implementation of PEP 383 can be simplified
significantly, essentially removing the need for a separate utf-8b codec
(as that could be done in the error handler, as for the other codecs).

----------
assignee:  -> benjamin.peterson
keywords: +patch
nosy: +benjamin.peterson
priority: high -> release blocker
Added file: http://bugs.python.org/file13827/surrogates.diff

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 11:21:50 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 09:21:50 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241169710.81.0.527088171459.issue3672@psf.upfronthosting.co.za>


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

rietveld: http://codereview.appspot.com/52081

----------

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

From report at bugs.python.org  Fri May  1 11:42:04 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 01 May 2009 09:42:04 +0000
Subject: [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: <1241170924.08.0.221922330138.issue5894@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Babel already provides (almost all of) this. It uses the Unicode CLDR
data to present the information you need.

See http://babel.edgewall.org/

----------
nosy: +asmodai

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

From report at bugs.python.org  Fri May  1 11:44:58 2009
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 01 May 2009 09:44:58 +0000
Subject: [issue4587] Need to rework the dbm lib/include selection process
In-Reply-To: <18748.30438.749825.192737@montanaro-dyndns-org.local>
Message-ID: <1241171098.75.0.916900825508.issue4587@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

applied on the py3k branch as well

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

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

From report at bugs.python.org  Fri May  1 12:35:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 10:35:34 +0000
Subject: [issue5883] detach() implementation
In-Reply-To: <1241165200.77.0.779938949951.issue5883@psf.upfronthosting.co.za>
Message-ID: <1241174241.5114.1.camel@localhost>


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

> The various structures now contain several 'boolean' flags. It would 
> improve memory usage to use bitfields. Or would this impact performance 
> ?

Those structures usually allocate a 4KB- or 8KB- buffer each, so I don't
think squeezing two or three bytes would do a lot of difference
(performance probably wouldn't be affected either).

Also, I don't find the bitfield notation very readable (and it isn't
found anywhere else in the interpreter AFAIK), but that's just me :-)

----------

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

From report at bugs.python.org  Fri May  1 12:37:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 May 2009 10:37:46 +0000
Subject: [issue5859] Remove implicit '%f' -> '%g' switch from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1241174266.66.0.396502674816.issue5859@psf.upfronthosting.co.za>


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

Here's a patch which doesn't fix the '%f' -> '%g' switch, but paves the
way for that switch by getting rid of the fixed-size buffers in
formatfloat in unicodeobject.c, and in the fallback version of
PyOS_double_to_string.

----------
keywords: +patch
Added file: http://bugs.python.org/file13828/issue5859_stage1.patch

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

From report at bugs.python.org  Fri May  1 12:50:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 May 2009 10:50:34 +0000
Subject: [issue5859] Remove implicit '%f' -> '%g' switch from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1241175034.48.0.196023497893.issue5859@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri May  1 12:59:21 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 01 May 2009 10:59:21 +0000
Subject: [issue5650] Obsolete RFC's should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1241175561.86.0.279613772701.issue5650@psf.upfronthosting.co.za>


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

Georg, shall I take up this one?

----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri May  1 13:04:57 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 01 May 2009 11:04:57 +0000
Subject: [issue1643370] recursive urlparse
Message-ID: <1241175897.74.0.943996999496.issue1643370@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri May  1 13:05:49 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 01 May 2009 11:05:49 +0000
Subject: [issue1591035] update urlparse to RFC 3986
Message-ID: <1241175949.99.0.668798925234.issue1591035@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri May  1 13:17:43 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 01 May 2009 11:17:43 +0000
Subject: [issue5861] test_urllib fails on windows
In-Reply-To: <1240883003.46.0.843478025116.issue5861@psf.upfronthosting.co.za>
Message-ID: <1241176663.16.0.196817419275.issue5861@psf.upfronthosting.co.za>


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

I had made that change. tested only linux, where it was all pass. Shall
address this one soon.

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

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

From report at bugs.python.org  Fri May  1 13:43:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 May 2009 11:43:32 +0000
Subject: [issue5859] Remove implicit '%f' -> '%g' switch from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1241178212.92.0.713630679499.issue5859@psf.upfronthosting.co.za>


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

No new test failures on Linux or OS X, with or without the fallback code.  
I've committed this in r72161.

----------

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

From report at bugs.python.org  Fri May  1 14:04:38 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 01 May 2009 12:04:38 +0000
Subject: [issue5859] Remove implicit '%f' -> '%g' switch from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1241179478.13.0.415087865023.issue5859@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch looks good to me.

----------

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

From report at bugs.python.org  Fri May  1 14:57:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 12:57:19 +0000
Subject: [issue5883] detach() implementation
In-Reply-To: <1241043589.42.0.224421532781.issue5883@psf.upfronthosting.co.za>
Message-ID: <1241182639.31.0.391957855417.issue5883@psf.upfronthosting.co.za>


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

The new patch looks good.

----------

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

From report at bugs.python.org  Fri May  1 15:15:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 May 2009 13:15:39 +0000
Subject: [issue5859] Remove implicit '%f' -> '%g' switch from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1241183739.68.0.956309927644.issue5859@psf.upfronthosting.co.za>


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

Here's the patch that actually removes the %f -> %g switch.

----------
Added file: http://bugs.python.org/file13829/issue5859_stage2.patch

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

From report at bugs.python.org  Fri May  1 15:27:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 May 2009 13:27:08 +0000
Subject: [issue5893] Add support to pydoc to output .rst restructured text
In-Reply-To: <1241161286.71.0.465888243083.issue5893@psf.upfronthosting.co.za>
Message-ID: <1241184428.97.0.377435766075.issue5893@psf.upfronthosting.co.za>


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

Personally I think that the Sphinx autodoc extension does a better job
of this than having pydoc export .rst would.  Is there some regard in
which that doesn't solve your problem?

----------
nosy: +r.david.murray
priority: normal -> low

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

From report at bugs.python.org  Fri May  1 17:24:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 May 2009 15:24:15 +0000
Subject: [issue5829] float('1e500') -> inf, complex('1e500') -> ValueError
In-Reply-To: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
Message-ID: <1241191455.33.0.785219807383.issue5829@psf.upfronthosting.co.za>


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


----------
assignee:  -> marketdickinson

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

From report at bugs.python.org  Fri May  1 17:38:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 May 2009 15:38:01 +0000
Subject: [issue5859] Remove implicit '%f' -> '%g' switch from float formatting.
In-Reply-To: <1240865404.22.0.619023104879.issue5859@psf.upfronthosting.co.za>
Message-ID: <1241192281.62.0.933942312051.issue5859@psf.upfronthosting.co.za>


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

Fixed in r72165.

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

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

From report at bugs.python.org  Fri May  1 17:47:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 01 May 2009 15:47:56 +0000
Subject: [issue5889] Extra comma in enum - fails on AIX
In-Reply-To: <1241117078.61.0.563622380824.issue5889@psf.upfronthosting.co.za>
Message-ID: <1241192876.99.0.828788248496.issue5889@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Georg, should this fix also be applied to the py3k branch as I am able
to repro this on 3.1a2?

----------

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

From report at bugs.python.org  Fri May  1 18:00:24 2009
From: report at bugs.python.org (Ben Gamari)
Date: Fri, 01 May 2009 16:00:24 +0000
Subject: [issue1555842] email package and Unicode strings handling
Message-ID: <1241193624.67.0.690805079179.issue1555842@psf.upfronthosting.co.za>


Changes by Ben Gamari <bgamari at gmail.com>:


----------
nosy: +bgamari

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

From report at bugs.python.org  Fri May  1 18:00:58 2009
From: report at bugs.python.org (Ben Gamari)
Date: Fri, 01 May 2009 16:00:58 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1241193658.7.0.450789414495.issue1685453@psf.upfronthosting.co.za>


Changes by Ben Gamari <bgamari at gmail.com>:


----------
nosy: +bgamari

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

From report at bugs.python.org  Fri May  1 18:18:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 May 2009 16:18:33 +0000
Subject: [issue5889] Extra comma in enum - fails on AIX
In-Reply-To: <1241117078.61.0.563622380824.issue5889@psf.upfronthosting.co.za>
Message-ID: <1241194713.62.0.991670682395.issue5889@psf.upfronthosting.co.za>


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

Yes, in fact it already has been merged.

----------

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

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: [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:10:47 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 May 2009 17:10:47 +0000
Subject: [issue5893] Add support to pydoc to output .rst restructured text
In-Reply-To: <1241161286.71.0.465888243083.issue5893@psf.upfronthosting.co.za>
Message-ID: <1241197847.81.0.815480063156.issue5893@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

oh. sphinx can already do this?  nevermind then.

*goes off to look closer at sphinx*

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

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

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: [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: [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 report at bugs.python.org  Fri May  1 20:50:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 May 2009 18:50:50 +0000
Subject: [issue5897] No library reference tree in chm help file
In-Reply-To: <1241203463.4.0.587684718574.issue5897@psf.upfronthosting.co.za>
Message-ID: <1241203850.78.0.915584641571.issue5897@psf.upfronthosting.co.za>


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

This is already tracked in #5764.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> 2.6.2 Python Manuals CHM file seems broken

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

From report at bugs.python.org  Fri May  1 20:55:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 May 2009 18:55:06 +0000
Subject: [issue5893] Add support to pydoc to output .rst restructured text
In-Reply-To: <1241161286.71.0.465888243083.issue5893@psf.upfronthosting.co.za>
Message-ID: <1241204106.02.0.501470263908.issue5893@psf.upfronthosting.co.za>


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

I'd like to note that what Sphinx can't do -- or better, doesn't do at
the moment, is to output full reStructuredText documents when using
autodoc.  It directly integrates the docstrings into the doctree that
will become the output.

So, for the Python documentation itself, where we do not want to use
autodoc (it would be nice, but would require that the documentation be
built using the version of Python that is documented, which is e.g.
currently impossible in the case of 3.x), this is of no great help.

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

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

From report at bugs.python.org  Fri May  1 20:56:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 May 2009 18:56:00 +0000
Subject: [issue5650] Obsolete RFC's should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1241204160.52.0.483534261862.issue5650@psf.upfronthosting.co.za>


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

Yes, you've probably a better understanding of what differentiates an
URL and URI than me :)

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 21:47:36 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 19:47:36 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241207256.98.0.637742040434.issue3672@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13827/surrogates.diff

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 21:48:32 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 19:48:32 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241207312.91.0.222609639884.issue3672@psf.upfronthosting.co.za>


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

Fixed indexing error.

----------
Added file: http://bugs.python.org/file13830/surrogates.diff

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 21:54:42 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 19:54:42 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241207682.75.0.606507524661.issue1443504@psf.upfronthosting.co.za>


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

The patch looks fine to me.

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

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

From report at bugs.python.org  Fri May  1 22:00:53 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 May 2009 20:00:53 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1241208053.67.0.378548946597.issue3959@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Committed to trunk (2.7) in r72173.  I'll merge it into py3k later this
afternoon.

----------
priority: normal -> release blocker
versions:  -Python 2.7

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

From report at bugs.python.org  Fri May  1 22:03:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 20:03:54 +0000
Subject: [issue1662] [patch] assert tp_traverse in PyType_GenericAlloc()
In-Reply-To: <1198084921.68.0.0736452990224.issue1662@psf.upfronthosting.co.za>
Message-ID: <1241208233.99.0.929246028646.issue1662@psf.upfronthosting.co.za>


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

It would be probably be better to put this check in PyType_Ready() instead.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Fri May  1 22:04:31 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 01 May 2009 20:04:31 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241208271.31.0.999101007885.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

OK, then I'll apply it.

But I am curious about your thoughts about the _parse_localename()
method being called from setlocale() raising a ValueError, whereas a
setlocale(LC_CTYPE, "") should not fail at all, which it currently does
if the locale in the environment is not valid.

----------

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

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: [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 22:16:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 20:16:59 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1241209019.27.0.699178100005.issue3959@psf.upfronthosting.co.za>


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

Is there any chance the test methods in test_ipaddr can be PEP8-ified?

----------

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

From report at bugs.python.org  Fri May  1 22:19:01 2009
From: report at bugs.python.org (pmoody)
Date: Fri, 01 May 2009 20:19:01 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1241209019.27.0.699178100005.issue3959@psf.upfronthosting.co.za>
Message-ID: <8517e9350905011318m3471f135wf47c5a48e43b0af6@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

I'll submit a change for this to trunk in a second.

On Fri, May 1, 2009 at 1:16 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Is there any chance the test methods in test_ipaddr can be PEP8-ified?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri May  1 22:23:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 20:23:48 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241209428.72.0.863816101892.issue5753@psf.upfronthosting.co.za>


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

What is the problem exactly?
An user can run arbitrary Python code from a file in his own account --
well, sure, that's a feature. Unless I'm misunderstanding something.

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 22:24:45 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 20:24:45 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
In-Reply-To: <1241208271.31.0.999101007885.issue1443504@psf.upfronthosting.co.za>
Message-ID: <49FB5A8B.50303@v.loewis.de>


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

> But I am curious about your thoughts about the _parse_localename()
> method being called from setlocale() raising a ValueError, whereas a
> setlocale(LC_CTYPE, "") should not fail at all, which it currently does
> if the locale in the environment is not valid.

I fail to see how this is related to this issue. In the OP's report,
the exception was locale.Error, not ValueError, and _parse_localename
isn't ever being called from setlocale() - why do you think it is being
called? AFAICT, the only callers of _parse_localename are getlocale and
getdefaultlocale (which, IMO, should both be deprecated).

----------

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

From report at bugs.python.org  Fri May  1 22:26:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 20:26:50 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241209610.87.0.923374056679.issue5753@psf.upfronthosting.co.za>


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

I wanted to read the patch at
https://bugzilla.redhat.com/attachment.cgi?id=334888 but apparently its
access is restricted...

----------

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

From =?utf-8?q?Fran=C3=A7ois_Granade_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Fri May  1 22:39:52 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:39:52 +0000
Subject: [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: <1241210392.35.0.355658501141.issue5898@psf.upfronthosting.co.za>


Fran?ois Granade <francois at granade.com> added the comment:

Note that I use this wait(), otherwise, on CygWin, proc1 does not
properly dies, and leaves opened (undeletable - that's windows !) files
around

----------

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

From report at bugs.python.org  Fri May  1 22:41:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 May 2009 20:41:22 +0000
Subject: [issue5883] detach() implementation
In-Reply-To: <1241043589.42.0.224421532781.issue5883@psf.upfronthosting.co.za>
Message-ID: <1241210482.85.0.772231353967.issue5883@psf.upfronthosting.co.za>


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

Applied in r72175.

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

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

From report at bugs.python.org  Fri May  1 22:58:52 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 01 May 2009 20:58:52 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241211532.9.0.373992635044.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Sorry, I was actually off by a method last night.

It turns out the problem lies in _localemodule.c.

Let me start with the basic question: is our setlocale() supposed to
mirror POSIX' operations/semantics?

----------

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

From report at bugs.python.org  Fri May  1 23:10:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:10:31 +0000
Subject: [issue3002] shutil.copyfile blocks indefinitely on named pipes
In-Reply-To: <1212075150.42.0.761610345558.issue3002@psf.upfronthosting.co.za>
Message-ID: <1241212231.85.0.68658054907.issue3002@psf.upfronthosting.co.za>


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

Committed in r72178, r72179. Thanks!

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May  1 23:11:08 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 01 May 2009 21:11:08 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
In-Reply-To: <1241211532.9.0.373992635044.issue1443504@psf.upfronthosting.co.za>
Message-ID: <49FB656A.1020706@v.loewis.de>


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

> Let me start with the basic question: is our setlocale() supposed to
> mirror POSIX' operations/semantics?

Yes, it is.

----------

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

From report at bugs.python.org  Fri May  1 23:22:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:22:50 +0000
Subject: [issue5726] ld_so_aix does exit successfully even in case of failure
In-Reply-To: <1239270884.66.0.724599515484.issue5726@psf.upfronthosting.co.za>
Message-ID: <1241212970.2.0.331764900384.issue5726@psf.upfronthosting.co.za>


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

Committed, thanks!

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

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

From report at bugs.python.org  Fri May  1 23:30:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 May 2009 21:30:49 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241213449.29.0.821681406925.issue3672@psf.upfronthosting.co.za>


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

http://codereview.appspot.com/52081/diff/1/5
File Doc/library/codecs.rst (right):

http://codereview.appspot.com/52081/diff/1/5#newcode326
Line 326: In addition, the following error handlers are specific to only
selected
"In addition, the following error handlers are specific to a single
codec." sounds better

http://codereview.appspot.com/52081/diff/1/5#newcode335
Line 335:
There should probably be a versionchanged directive indicating that
"surrogates" was added in 3.1.

http://codereview.appspot.com/52081/diff/1/6
File Lib/test/test_codecs.py (right):

http://codereview.appspot.com/52081/diff/1/6#newcode544
Line 544: def test_surrogates(self):
I think this should be split into 2 tests. "test_lone_surrogates" and
"test_surrogate_handler".

http://codereview.appspot.com/52081/diff/1/4
File Objects/unicodeobject.c (right):

http://codereview.appspot.com/52081/diff/1/4#newcode157
Line 157: static PyObject *unicode_encode_call_errorhandler(const char
*errors,
These prototypes are longer than 80 chars some places. I don't think the
arguments need to line up with the starting parenthesis.

http://codereview.appspot.com/52081/diff/1/4#newcode2393
Line 2393: s, size, &exc, i-1, i, &newpos);
"exc" is never Py_DECREFed.

http://codereview.appspot.com/52081/diff/1/4#newcode4110
Line 4110: if (!PyUnicode_Check(repunicode)) {
Is there a test of this case somewhere?

http://codereview.appspot.com/52081/diff/1/2
File Python/codecs.c (right):

http://codereview.appspot.com/52081/diff/1/2#newcode758
Line 758: if (PyObject_IsInstance(exc, PyExc_UnicodeEncodeError)) {
I believe PyErr_GivenExceptionMatches is more appropriate here, but
given the rest of the file uses PyObject_IsInstance, it likely doesn't
matter.

http://codereview.appspot.com/52081/diff/1/2#newcode771
Line 771: return NULL;
This is leaks "object".

http://codereview.appspot.com/52081

----------

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

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: [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  Fri May  1 23:39:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:39:13 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1241213953.92.0.132790980945.issue5596@psf.upfronthosting.co.za>


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

Current status here:

test_multiprocessing leaked [24, 0] references, sum=24
test_urllib2 leaked [227, 227] references, sum=454
test_urllib2_localnet leaked [3, 3] references, sum=6

----------

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

From report at bugs.python.org  Fri May  1 23:39:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:39:17 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1241213957.49.0.994977084663.issue5596@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13459/py3k_fix_leak_of_fileio.patch

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

From report at bugs.python.org  Fri May  1 23:39:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:39:20 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1241213960.35.0.622713689375.issue5596@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13460/py3k_fix_leak_of_test_socket.patch

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

From report at bugs.python.org  Fri May  1 23:42:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 May 2009 21:42:46 +0000
Subject: [issue5410] msvcrt bytes cleanup
In-Reply-To: <1236081375.11.0.544682804494.issue5410@psf.upfronthosting.co.za>
Message-ID: <1241214166.56.0.109039622211.issue5410@psf.upfronthosting.co.za>


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

Applied in r72185.

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

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

From report at bugs.python.org  Fri May  1 23:48:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:48:35 +0000
Subject: [issue2116] weakref copy module interaction
In-Reply-To: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>
Message-ID: <1241214515.15.0.142069187469.issue2116@psf.upfronthosting.co.za>


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

Raymond, Guido, any opinion on this one?

----------
assignee: tim_one -> 
nosy: +gvanrossum, rhettinger
stage:  -> patch review
versions: +Python 2.7, Python 3.1 -Python 2.5

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

From report at bugs.python.org  Fri May  1 23:50:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:50:41 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1241214641.44.0.967862477086.issue5006@psf.upfronthosting.co.za>


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


----------
nosy: +lemburg

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

From report at bugs.python.org  Fri May  1 23:53:18 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 May 2009 21:53:18 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241214798.77.0.828289123146.issue5890@psf.upfronthosting.co.za>


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

What is happening here is that when __doc__ is looked up, it is found
first among the attributes of the class type.  __doc__ is special, and
types define it to be None if it not set to anything specific.  So the
docstring for an instance of a subclass of property is None, or the
docstring of the subclass if one is provided.  The other property
attributes aren't affected since they aren't "special" attributes on
types, and so get looked up on the base class as expected.

I believe the fix is to have property's __init__ check to see if it is
dealing with a subclass, and if so to insert the __doc__ string into the
instance's __dict__.

Patch attached.  Needs review, especially since I'm new to internals stuff.

----------
assignee:  -> r.david.murray
components: +Interpreter Core
keywords: +needs review, patch
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13831/issue5890.patch

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

From report at bugs.python.org  Fri May  1 23:54:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:54:59 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1241214899.32.0.844808672866.issue5084@psf.upfronthosting.co.za>


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

Jake, are you string working on a test?

----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri May  1 23:55:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 21:55:33 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1241214933.88.0.545753715465.issue5084@psf.upfronthosting.co.za>


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

(s/string/still/, of course...)

----------

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

From report at bugs.python.org  Sat May  2 00:03:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 22:03:42 +0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1241215422.48.0.80822865762.issue2181@psf.upfronthosting.co.za>


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

Given that it is unlikely to give any speedup in real-world code, I
don't think we should add complexity to the compiler. Recommend closing.

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

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

From report at bugs.python.org  Sat May  2 00:10:00 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 May 2009 22:10:00 +0000
Subject: [issue5867] No way to create an abstract classmethod
In-Reply-To: <1240928652.35.0.147355180867.issue5867@psf.upfronthosting.co.za>
Message-ID: <1241215800.27.0.676098389771.issue5867@psf.upfronthosting.co.za>


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

Please ask questions like this first on python-list or the c.l.p or
gmane mirrors.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Sat May  2 00:20:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 May 2009 22:20:35 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241216435.75.0.0438703866788.issue5890@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13831/issue5890.patch

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

From report at bugs.python.org  Sat May  2 00:22:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 May 2009 22:22:26 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241216546.86.0.992126034018.issue5890@psf.upfronthosting.co.za>


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

Fixes from review on #python-dev by Benjamin.

It looks like I also need to look at property_copy.

----------
Added file: http://bugs.python.org/file13832/issue5890.patch

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

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: [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 01:49:19 2009
From: report at bugs.python.org (pmoody)
Date: Fri, 01 May 2009 23:49:19 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8517e9350905011318m3471f135wf47c5a48e43b0af6@mail.gmail.com>
Message-ID: <8517e9350905011649q4174174bw35e100f1bba5966d@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

well, sent it for review anyway.  is this a showstopper for submission?

On Fri, May 1, 2009 at 1:19 PM, pmoody <report at bugs.python.org> wrote:
>
> pmoody <python at hda3.com> added the comment:
>
> I'll submit a change for this to trunk in a second.
>
> On Fri, May 1, 2009 at 1:16 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>>
>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>
>> Is there any chance the test methods in test_ipaddr can be PEP8-ified?
>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue3959>
>> _______________________________________
>>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat May  2 01:50:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 May 2009 23:50:13 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1241221813.02.0.451385633226.issue3959@psf.upfronthosting.co.za>


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

Not at all, it's just nicer.

----------

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

From report at bugs.python.org  Sat May  2 02:28:06 2009
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Sat, 02 May 2009 00:28:06 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241224086.28.0.489333684468.issue5753@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at divmod.com> added the comment:

Antoine,

The problem is that apparently every program that embeds Python calls
PySys_SetArgv and does not understand the consequences of doing so.  For
example, a user running 'gedit' to edit some files in a potentially
insecure directory may not expect that starting the program there will
cause it to load python files from that directory.

The 'python' executable itself is not really "vulnerable" in quite the
same way, because if you (i.e. a developer) start 'python' in some
directory, you *do* typically expect that it will load code from that
directory.  For applications written *in* python, that have scripts in,
let's say, /usr/bin, the directory added to the path is /usr/bin, not
the application's working directory.

----------

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

From report at bugs.python.org  Sat May  2 02:48:26 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 May 2009 00:48:26 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1241225306.98.0.0370138135743.issue3959@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I merged ipaddr into py3k.

I can't lookup the revision number (r72186?) at the moment since 
svn.python.org is having problems.

anyways, thanks pmoody & other ipaddr developers!

Now that the library is -in- (before the 3.1 beta cutoff :), non-API 
changing bug fixes and tweaks like that one are fine to apply to the 
python svn repo as appropriate.

I'm leaving this open pending merging the test pep8 change in once it is 
ready and svn.python.org is back online.

----------
priority: release blocker -> normal
resolution:  -> accepted

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

From report at bugs.python.org  Sat May  2 02:50:29 2009
From: report at bugs.python.org (Matthew Smart)
Date: Sat, 02 May 2009 00:50:29 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1241225306.98.0.0370138135743.issue3959@psf.upfronthosting.co.za>
Message-ID: <567bcae60905011750t43b31b6cg9def3dac4c8f6887@mail.gmail.com>


Matthew Smart <mattsmart at gmail.com> added the comment:

Woo!

On May 1, 2009 5:48 PM, "Gregory P. Smith" <report at bugs.python.org> wrote:

Gregory P. Smith <greg at krypto.org> added the comment:
I merged ipaddr into py3k.

I can't lookup the revision number (r72186?) at the moment since
svn.python.org is having problems.

anyways, thanks pmoody & other ipaddr developers!

Now that the library is -in- (before the 3.1 beta cutoff :), non-API
changing bug fixes and tweaks like that one are fine to apply to the
python svn repo as appropriate.

I'm leaving this open pending merging the test pep8 change in once it is
ready and svn.python.org is back online.

----------
priority: release blocker -> normal
resolution:  -> accepted

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

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________
-------------- next part --------------
<p>Woo!</p>
<p><blockquote type="cite">On May 1, 2009 5:48 PM, &quot;Gregory P. Smith&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><p><font color="#500050">
Gregory P. Smith &lt;<a href="mailto:greg at krypto.org">greg at krypto.org</a>&gt; added the comment:

</font></p>I merged ipaddr into py3k.<br>
<br>
I can&#39;t lookup the revision number (r72186?) at the moment since<br>
<a href="http://svn.python.org" target="_blank">svn.python.org</a> is having problems.<br>
<br>
anyways, thanks pmoody &amp; other ipaddr developers!<br>
<br>
Now that the library is -in- (before the 3.1 beta cutoff :), non-API<br>
changing bug fixes and tweaks like that one are fine to apply to the<br>
python svn repo as appropriate.<br>
<br>
I&#39;m leaving this open pending merging the test pep8 change in once it is<br>
ready and <a href="http://svn.python.org" target="_blank">svn.python.org</a> is back online.<br>
<br>
----------<br>
priority: release blocker -&gt; normal<br>
resolution: ??-&gt; accepted<br>
<p><font color="#500050">
_______________________________________
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;
&lt;<a href="http://bugs.python.">http://bugs.python.</a>..</font></p></blockquote></p>

From report at bugs.python.org  Sat May  2 03:00:43 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 May 2009 01:00:43 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1241226043.31.0.480556196678.issue3959@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------

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

From report at bugs.python.org  Sat May  2 04:38:06 2009
From: report at bugs.python.org (Jake McGuire)
Date: Sat, 02 May 2009 02:38:06 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1241231886.8.0.453642339448.issue5084@psf.upfronthosting.co.za>


Jake McGuire <jake at youtube.com> added the comment:

This fell through the cracks.  But the following unit test seems like it 
does the right thing (fails with the old module, works with the new ones).

----------
Added file: http://bugs.python.org/file13835/pickletester.diff

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

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: [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 09:47:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 May 2009 07:47:56 +0000
Subject: [issue5901] missing meta-info in documentation pdf
In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za>
Message-ID: <1241250476.86.0.993279057592.issue5901@psf.upfronthosting.co.za>


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

I thought we already did assign these metadata items; looks like it's
been messed up somehow.  I'll fix this.

----------

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

From report at bugs.python.org  Sat May  2 10:00:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 May 2009 08:00:21 +0000
Subject: [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 10:38:45 2009
From: report at bugs.python.org (James Andrewartha)
Date: Sat, 02 May 2009 08:38:45 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1241253525.77.0.507029604315.issue1759169@psf.upfronthosting.co.za>


James Andrewartha <trs80 at ucc.gu.uwa.edu.au> added the comment:

I'm jhbuilding GNOME on Solaris, and the attached patch fixes the
problem for me, having compiled Python with it I can now compile
dbus-python, pycairo and pyorbit against it.

----------
nosy: +trs80

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

From report at bugs.python.org  Sat May  2 11:20:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 May 2009 09:20:26 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241256026.69.0.184003855831.issue5902@psf.upfronthosting.co.za>


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

I don't think this is a good idea.  Accepting all common forms for
encoding names means that you can usually give Python an encoding name
from, e.g. a HTML page, or any other file or system that specifies an
encoding.  If we only supported, e.g., "UTF-8" and no other spelling,
that would make life much more difficult.  If you look into
encodings/__init__.py, you can see that throwing out all
non-alphanumerics is a conscious design choice in encoding name
normalization.

The only thing I don't know is why "utf" is an alias for utf-8.

Assigning to Marc-Andre, who implemented most of codecs.

----------
assignee: georg.brandl -> lemburg
nosy: +lemburg
resolution:  -> rejected
status: open -> pending

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  2 11:44:08 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 09:44:08 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <000e0ce0719c051cb50468eac57e@google.com>


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

Reviewers: report_bugs.python.org, Benjamin,

Message:
Issues fixed in r72188.

http://codereview.appspot.com/52081/diff/1/5
File Doc/library/codecs.rst (right):

http://codereview.appspot.com/52081/diff/1/5#newcode326
Line 326: In addition, the following error handlers are specific to only
selected
On 2009/05/01 21:25:44, Benjamin wrote:
> "In addition, the following error handlers are specific to a single
codec."
> sounds better

Done.

http://codereview.appspot.com/52081/diff/1/5#newcode335
Line 335:
On 2009/05/01 21:25:44, Benjamin wrote:
> There should probably be a versionchanged directive indicating that
"surrogates"
> was added in 3.1.

Done.

http://codereview.appspot.com/52081/diff/1/6
File Lib/test/test_codecs.py (right):

http://codereview.appspot.com/52081/diff/1/6#newcode544
Line 544: def test_surrogates(self):
On 2009/05/01 21:25:44, Benjamin wrote:
> I think this should be split into 2 tests. "test_lone_surrogates" and
> "test_surrogate_handler".

Done.

http://codereview.appspot.com/52081/diff/1/4
File Objects/unicodeobject.c (right):

http://codereview.appspot.com/52081/diff/1/4#newcode157
Line 157: static PyObject *unicode_encode_call_errorhandler(const char
*errors,
On 2009/05/01 21:25:44, Benjamin wrote:
> These prototypes are longer than 80 chars some places. I don't think
the
> arguments need to line up with the starting parenthesis.

Done.

http://codereview.appspot.com/52081/diff/1/4#newcode2393
Line 2393: s, size, &exc, i-1, i, &newpos);
On 2009/05/01 21:25:44, Benjamin wrote:
> "exc" is never Py_DECREFed.

Done.

http://codereview.appspot.com/52081/diff/1/4#newcode4110
Line 4110: if (!PyUnicode_Check(repunicode)) {
On 2009/05/01 21:25:44, Benjamin wrote:
> Is there a test of this case somewhere?

No. This is temporary - for PEP 383, I will have to support error
handlers returning bytes here, also.

http://codereview.appspot.com/52081/diff/1/2
File Python/codecs.c (right):

http://codereview.appspot.com/52081/diff/1/2#newcode758
Line 758: if (PyObject_IsInstance(exc, PyExc_UnicodeEncodeError)) {
On 2009/05/01 21:25:44, Benjamin wrote:
> I believe PyErr_GivenExceptionMatches is more appropriate here, but
given the
> rest of the file uses PyObject_IsInstance, it likely doesn't matter.

No. The interface is that an exception instance must be passed;
GivenExceptionMatches would also allow for tuples and types.

http://codereview.appspot.com/52081/diff/1/2#newcode771
Line 771: return NULL;
On 2009/05/01 21:25:44, Benjamin wrote:
> This is leaks "object".

Done.

Please review this at http://codereview.appspot.com/52081

Affected files:
   M     Doc/library/codecs.rst
   M     Lib/test/test_bytes.py
   M     Lib/test/test_codecs.py
   M     Lib/test/test_unicode.py
   M     Lib/test/test_unicodedata.py
   M     Objects/unicodeobject.c
   M     Python/codecs.c
   M     Python/marshal.c

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  2 11:47:45 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 09:47:45 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241257665.61.0.554258373012.issue3672@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13830/surrogates.diff

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  2 11:48:08 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 09:48:08 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241257688.8.0.602021367841.issue3672@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file13836/surrogates.diff

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

From report at bugs.python.org  Sat May  2 13:35:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 11:35:27 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241264127.44.0.195406722707.issue5902@psf.upfronthosting.co.za>


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

Is there any reason for allowing "utf" as an alias to utf-8? It sounds
much too ambiguous. The other silly variants (those with lots of
spurious puncutuations characters) could be forbidden too.

----------
nosy: +pitrou
status: pending -> open

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

From report at bugs.python.org  Sat May  2 13:39:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 11:39:36 +0000
Subject: [issue5880] Remove unneeded "context" pointer from getters and setters
In-Reply-To: <1241021724.62.0.808491876443.issue5880@psf.upfronthosting.co.za>
Message-ID: <1241264376.18.0.972671258238.issue5880@psf.upfronthosting.co.za>


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

Doesn't it also break binary compatibility with extension modules?
Perhaps this should be quickly discussed on python-dev, although I agree
that it looks sensible.

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

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

From report at bugs.python.org  Sat May  2 13:40:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 11:40:40 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1241264440.56.0.200063742525.issue5084@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May  2 13:41:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 11:41:40 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1241264500.81.0.700953861479.issue5084@psf.upfronthosting.co.za>


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

Thanks, I'll take a look very soon.

----------
assignee: alexandre.vassalotti -> pitrou

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

From report at bugs.python.org  Sat May  2 14:15:36 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 02 May 2009 12:15:36 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1241266536.71.0.81239335459.issue3379@psf.upfronthosting.co.za>


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

Committed in revision 71291.

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

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

From report at bugs.python.org  Sat May  2 14:16:26 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 02 May 2009 12:16:26 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1241266586.97.0.53812405601.issue3379@psf.upfronthosting.co.za>


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

No, make that revision 72191. :-)

----------

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

From report at bugs.python.org  Sat May  2 14:37:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 12:37:11 +0000
Subject: [issue4136] merge json library with latest simplejson 2.0.x
In-Reply-To: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>
Message-ID: <1241267831.96.0.177280990071.issue4136@psf.upfronthosting.co.za>


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

Since no other patches were proposed, I applied Antoine's patch in r72194.

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

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

From report at bugs.python.org  Sat May  2 14:44:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 12:44:34 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241268274.0.0.066225969637.issue5753@psf.upfronthosting.co.za>


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

I'm not sure we can change the behaviour of PySys_SetArgv() like that.
At least not in a bugfix release.
In 2.7/3.1, we could either change PySys_SetArgv(), or introduce a new
PySys_SetArgvEx() with an additional argument indicating whether
sys.path should be modified or not. I suggest asking on python-dev first.

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

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

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: [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:22:43 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 May 2009 13:22:43 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241270563.51.0.223965857927.issue5903@psf.upfronthosting.co.za>


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

See http://bugs.python.org/issue5398

----------
nosy: +ezio.melotti

_______________________________________
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: [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 15:35:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 May 2009 13:35:35 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241271335.27.0.0447981592881.issue5903@psf.upfronthosting.co.za>


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

Here the issue might be different though. Does 
$ LC_ALL=ru_RU.koi8-r python3.0 -c 'import time;time.strftime("%A")'
(without the print) work?

I don't have the ru_RU locale but here time.strftime() return 'str', not
'bytes' and the utf-8 codec should be able to encode it:
>>> time.strftime("%A")
'Saturday'
>>> type(_)
<class 'str'>

----------

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

From report at bugs.python.org  Sat May  2 16:16:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 May 2009 14:16:08 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241273768.48.0.215554740725.issue5903@psf.upfronthosting.co.za>


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

I was able to reproduce this using an italian locale on Windows:
>>> locale.setlocale(locale.LC_TIME, 'Italian_Italy.1252')
'Italian_Italy.1252'
>>> time.strftime("%A", time.strptime("2009-05-01", "%Y-%m-%d"))
'venerd?'

That should be 'venerd?'.
I also found http://bugs.python.org/issue3061 and
http://bugs.python.org/issue836035 that seem to be related. (#5398
instead doesn't seem to be related.)

Apparently on Py3.x a unicode string ('str') is returned, whereas Py2.x
returns an encoded string:
>>> time.strftime("%A", time.strptime("2009-05-01", "%Y-%m-%d"))
'venerd\xec'

----------

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

From report at bugs.python.org  Sat May  2 16:53:10 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sat, 02 May 2009 14:53:10 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1241275990.18.0.451211627529.issue3061@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

As C99 section 7.23.3.5 states:

"Each conversion specifier is replaced by appropriate characters as
described in the following list. The appropriate characters are
determined using the LC_TIME category of the current locale and by the
values of zero or more members of the broken-down time structure pointed
to by timeptr, as specified in brackets in the description."

----------
nosy: +asmodai

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

From report at bugs.python.org  Sat May  2 17:08:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 15:08:15 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241276895.99.0.734380506851.issue5903@psf.upfronthosting.co.za>


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

Same thing here (Linux) with a non-utf8 locale:

>>> locale.setlocale(locale.LC_TIME, "fr_FR.UTF-8")
'fr_FR.UTF-8'
>>> time.strftime("%B", time.strptime("2009-12-01", "%Y-%m-%d"))
'd?cembre'
>>> locale.setlocale(locale.LC_TIME, "fr_FR.ISO8859-15")
'fr_FR.ISO8859-15'
>>> time.strftime("%B", time.strptime("2009-12-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

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

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

From report at bugs.python.org  Sat May  2 17:08:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 15:08:29 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241276909.84.0.189995568531.issue5903@psf.upfronthosting.co.za>


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


----------
priority:  -> high
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1

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

From report at bugs.python.org  Sat May  2 17:10:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 15:10:47 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1241277047.32.0.26115288146.issue5903@psf.upfronthosting.co.za>


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

Well, sorry for the message above. There is a problem but it is with
strptime() actually.

>>> time.strptime("2009-12-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

----------

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

From report at bugs.python.org  Sat May  2 17:12:06 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Sat, 02 May 2009 15:12:06 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241277126.61.0.697676480594.issue5752@psf.upfronthosting.co.za>


Changes by Francesco Sechi <francesco.sechi at iet.unipi.it>:


----------
nosy: +sechi_francesco

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

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


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

Well, it turns out that strftime() is buggy as well:

>>> tp = time.strptime("2009-12-01", "%Y-%m-%d")
>>> locale.setlocale(locale.LC_TIME, "fr_FR.ISO8859-15")
'fr_FR.ISO8859-15'
>>> time.strftime("%B", tp)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3:
invalid data

----------

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

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: [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 17:32:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 15:32:14 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241278334.17.0.210531837878.issue3672@psf.upfronthosting.co.za>


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

I think the new patch looks fine.

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

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

From report at bugs.python.org  Sat May  2 17:50:59 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Sat, 02 May 2009 15:50:59 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241279459.04.0.436503974947.issue5752@psf.upfronthosting.co.za>


Changes by Francesco Sechi <francesco.sechi at iet.unipi.it>:


Added file: http://bugs.python.org/file13837/test_toxml.py

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

From report at bugs.python.org  Sat May  2 17:57:34 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 15:57:34 +0000
Subject: [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1241279854.54.0.554412594433.issue5692@psf.upfronthosting.co.za>


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

Can someone try this patch, please?

----------
keywords: +patch
Added file: http://bugs.python.org/file13838/no_drive.patch

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

From report at bugs.python.org  Sat May  2 18:22:04 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 02 May 2009 16:22:04 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241281324.18.0.837565501172.issue5902@psf.upfronthosting.co.za>


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

How about a 'full' form and a 'key' form generated by the function:

def codec_key(name):
    return name.lower().replace("-", "").replace("_", "")

The key form would be the key to an available codec, and the key
generated by a user-supplied codec name would have to match one of those
keys.

For example:

Full: "UTF-8", key: "utf8".

Full: "ISO-8859-1", key: "iso88591".

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

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

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: [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:29:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 16:29:22 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1241281762.57.0.69725773754.issue5906@psf.upfronthosting.co.za>


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


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/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: [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 18:52:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 02 May 2009 16:52:47 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1241283167.12.0.352145842718.issue5906@psf.upfronthosting.co.za>


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

The multiprocessing lib mimics the threading library, and the 
threading.Thread.daemon has always maintained these are not 
services/daemons/etc.

I don't see that the clarification is needed, but let me think about it.

----------

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

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


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I agree that for someone who discovers the multiprocessing api as a
"generalization" of the threading api, there won't be problems ; 

I'm just worried about those (like me) who will see "daemonic" as coming
from unix processes, and not the threading library B-)

Cheers, 
pascal

----------

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

From report at bugs.python.org  Sat May  2 20:03:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 May 2009 18:03:19 +0000
Subject: [issue5880] Remove unneeded "context" pointer from getters and setters
In-Reply-To: <1241021724.62.0.808491876443.issue5880@psf.upfronthosting.co.za>
Message-ID: <1241287399.29.0.256563732746.issue5880@psf.upfronthosting.co.za>


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

I've removed those gratuitous context uses in Objects/longobject.c
in r72202 (trunk) and r72203 (py3k).

I'm not sure it's a good idea to remove the context field completely.  
Apart from the compatibility issues that Antoine pointed out, it
doesn't seem improbable that some getters and setters might need it.

A Google code search for PyGetSetDef turned up at least one non-null
use of the context field (in something called pyephem).  I didn't
look at it closely, though.

----------

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

From report at bugs.python.org  Sat May  2 20:16:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 May 2009 18:16:54 +0000
Subject: [issue5858] Make complex repr and str more like float repr and str
In-Reply-To: <1240865108.11.0.174510817411.issue5858@psf.upfronthosting.co.za>
Message-ID: <1241288214.3.0.215828824647.issue5858@psf.upfronthosting.co.za>


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

I'm not going to pursue this further;  try as I might, I really can't
make this anything more than just a personal preference.  It doesn't
solve any genuine problem.

Closing.

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  2 20:24:11 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 18:24:11 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1241288651.87.0.781059467562.issue5907@psf.upfronthosting.co.za>


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

Notice that this is no bug: there is no guarantee that repr() can
eval(). For some types it does, for others, it doesn't.

----------
nosy: +loewis
type: behavior -> feature request

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

From report at bugs.python.org  Sat May  2 20:34:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 May 2009 18:34:49 +0000
Subject: [issue1588] str.format() wrongly formats complex() numbers (Py30a2)
In-Reply-To: <1197379851.58.0.0476028374566.issue1588@psf.upfronthosting.co.za>
Message-ID: <1241289289.26.0.250193245047.issue1588@psf.upfronthosting.co.za>


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

One comment on the new complex formatting.  I now get (in py3k)

>>> from math import pi, e
>>> format(complex(pi,e), '<')
'(3.14159+2.71828j)'
>>> format(complex(pi,e), '')
'(3.14159265359+2.71828182846j)'

I understand why this is happening, but again I think that alignment 
flags shouldn't change the form of the number itself.  Would it be 
reasonable to have the empty format code always use a precision of 12?

----------

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

From report at bugs.python.org  Sat May  2 20:54:27 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 02 May 2009 18:54:27 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241290467.44.0.982216343316.issue5311@psf.upfronthosting.co.za>


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

Ok, I've been chatting with folks on microsoft.public.platformsdk.msi,
and I think the right approach here is to define a Feature for each
version of Python. Each Feature would install the exact same files, but
to a different Python directory.

One of the nice things about this approach would be that you could
install a module for multiple Python versions all at the same time. It
also should avoid the need for a VBScript or C-based CustomAction - we
should be able to do everything with the database tables.

One of the downsides is that we'll have to hard-code in all possible
versions of Python. My current plan is just to declare all versions as
2.0, 2.1, ..., 3.9. That should be good enough for a while, but at some
point this will have to get updated to work with Python 4.0. ;-)

I'll post back here when I've made some progress on this.

----------

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

From report at bugs.python.org  Sat May  2 20:54:30 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 18:54:30 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241290470.15.0.771418742256.issue3672@psf.upfronthosting.co.za>


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

Something I overlooked is that PyCodec_SurrogateErrors isn't exposed in
any headers.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  2 20:57:29 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 18:57:29 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1241290649.93.0.177159353653.issue3672@psf.upfronthosting.co.za>


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

Committed as r72208, blocked as r72209.

As for PyCodec_SurrogateErrors: I'd rather make it static than expose it.

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

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

From report at bugs.python.org  Sat May  2 21:01:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 19:01:15 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1241290649.93.0.177159353653.issue3672@psf.upfronthosting.co.za>
Message-ID: <1afaf6160905021201h72f81e53v75c27b7ecaffdd18@mail.gmail.com>


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

2009/5/2  <"\"Martin v. L?wis\"
<report at bugs.python.org>"@psf.upfronthosting.co.za>:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Committed as r72208, blocked as r72209.
>
> As for PyCodec_SurrogateErrors: I'd rather make it static than expose it.

Why? All the other error handlers are exposed.

----------

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

From report at bugs.python.org  Sat May  2 21:05:54 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 02 May 2009 19:05:54 +0000
Subject: [issue1607951] mailbox.Maildir re-reads directory too often
Message-ID: <1241291154.74.0.264871955649.issue1607951@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Updated version of the patch that only stores the current time -1sec,
adds a test case, and passes all tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file13839/mailbox-mtime.patch

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  2 21:11:04 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 19:11:04 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1afaf6160905021201h72f81e53v75c27b7ecaffdd18@mail.gmail.com>
Message-ID: <49FC9AC4.6010608@v.loewis.de>


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

>> As for PyCodec_SurrogateErrors: I'd rather make it static than expose it.
> 
> Why? All the other error handlers are exposed.

Sure - but what for? IMO, they all shouldn't be exposed.

----------

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

From report at bugs.python.org  Sat May  2 21:15:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 May 2009 19:15:10 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <49FC9AC4.6010608@v.loewis.de>
Message-ID: <1afaf6160905021215tfa616cej6b63607f4ab1bc7a@mail.gmail.com>


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

2009/5/2  <"\"Martin v. L?wis\"
<report at bugs.python.org>"@psf.upfronthosting.co.za>:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>>> As for PyCodec_SurrogateErrors: I'd rather make it static than expose it.
>>
>> Why? All the other error handlers are exposed.
>
> Sure - but what for? IMO, they all shouldn't be exposed.

The only reason I can think of is consistency, but I don't care that much.

----------

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

From report at bugs.python.org  Sat May  2 21:33:23 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 02 May 2009 19:33:23 +0000
Subject: [issue1588] str.format() wrongly formats complex() numbers (Py30a2)
In-Reply-To: <1197379851.58.0.0476028374566.issue1588@psf.upfronthosting.co.za>
Message-ID: <1241292803.96.0.0880534362328.issue1588@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Is this suggestion for all types, or just complex? Because float has the
same issue.

>>> format(pi, '')
'3.14159265359'
[38243 refs]
>>> format(pi, '>')
'3.14159'

----------

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

From report at bugs.python.org  Sat May  2 21:37:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 May 2009 19:37:47 +0000
Subject: [issue1588] str.format() wrongly formats complex() numbers (Py30a2)
In-Reply-To: <1197379851.58.0.0476028374566.issue1588@psf.upfronthosting.co.za>
Message-ID: <1241293067.04.0.663319937394.issue1588@psf.upfronthosting.co.za>


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

Hmm.  That also seems wrong to me.  So I guess it's a suggestion
for float as well, which means it's not specific to this issue.
Should I open a separate feature request?

----------

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

From report at bugs.python.org  Sat May  2 21:49:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 19:49:32 +0000
Subject: [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1241293772.39.0.353535160659.issue5692@psf.upfronthosting.co.za>


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

I don't think your patch is specific enough. It should only trigger when
the targetpath is of the form "/" or "X:/".
By the way, while I first rated this bug release blocker, thinking
test_zipfile was failing for all Windows platforms, we can downgrade it
if it only happens in a root directory.

----------

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

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: [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 21:57:53 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 02 May 2009 19:57:53 +0000
Subject: [issue1588] str.format() wrongly formats complex() numbers (Py30a2)
In-Reply-To: <1241293067.04.0.663319937394.issue1588@psf.upfronthosting.co.za>
Message-ID: <49FCA638.7050807@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

> Hmm.  That also seems wrong to me.  So I guess it's a suggestion
> for float as well, which means it's not specific to this issue.
> Should I open a separate feature request?

Yes, this is a separate issue. It comes from PEP 3101's specification of 
"like 'g' but different" for floats with no specified presentation type.

----------

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

From report at bugs.python.org  Sat May  2 22:21:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 20:21:18 +0000
Subject: [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1241295678.43.0.703839694656.issue5692@psf.upfronthosting.co.za>


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

This alternate patch is ok here (tested under Windows and Linux).
It's against trunk, since the bug actually exists there too.

----------
Added file: http://bugs.python.org/file13840/issue5692.patch

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

From report at bugs.python.org  Sat May  2 22:21:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 20:21:26 +0000
Subject: [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1241295686.98.0.618888285591.issue5692@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Sat May  2 22:22:02 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 02 May 2009 20:22:02 +0000
Subject: [issue5679] cleanUp stack for unittest
In-Reply-To: <1238788607.78.0.0557494613751.issue5679@psf.upfronthosting.co.za>
Message-ID: <1241295722.3.0.921718549861.issue5679@psf.upfronthosting.co.za>


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

Committed in revision 72219.

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

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

From report at bugs.python.org  Sat May  2 22:22:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 May 2009 20:22:03 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1241295723.82.0.990622131776.issue5907@psf.upfronthosting.co.za>


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

Also, the 2.5 behavior was not up to spec either: after eval() you get a
simple tuple, while the object before was a time.struct_time object.

(True, you can pass these tuples to the time functions, but an
eval()able repr() should reproduce the object exactly.)

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

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

From report at bugs.python.org  Sat May  2 22:54:15 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 02 May 2009 20:54:15 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241297655.73.0.134067921956.issue5311@psf.upfronthosting.co.za>


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

Ok, that was actually easier than I thought it would be. The new patch
introduces properties for each Python version (e.g. TARGETDIR2.4,
PYTHON.MACHINE.2.4, etc.), and disables and hides the features for any
Python versions that aren't found in the registry.

The one remaining issue: What should we do about Python installations
that are missing the appropriate keys in the registry? I imagine this
could happen if, say, you build Python from source. My first thought was
to add an "Other Python Installation" Feature that is disabled (but
visible) by default, and allow the path for that Feature to be filled in
by hand. Does that make sense?

----------
Added file: http://bugs.python.org/file13841/bdist_msi.patch

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

From report at bugs.python.org  Sat May  2 23:14:14 2009
From: report at bugs.python.org (Gerald Britton)
Date: Sat, 02 May 2009 21:14:14 +0000
Subject: [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:42:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 May 2009 21:42:51 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1241300571.09.0.905354966041.issue5084@psf.upfronthosting.co.za>


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

Committed in r72223, r72224. Thanks!

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

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

From report at bugs.python.org  Sat May  2 23:48:34 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sat, 02 May 2009 21:48:34 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241300914.39.0.216667218535.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

I will first point out where our current implementation is broken, in my
opinion of course, after which I propose a small patch.

Both C90 (7.4.1.1) and C99 (7.11.1.1) state:

"A value of "C" for locale specifies the minimal environment for C
translation; a value of "" for locale specifies the locale-specific
native environment. Other implementation-defined strings may be passed
as the second argument to setlocale.

[...]

If a pointer to a string is given for locale and the selection can be
honored, the setlocale function returns a pointer to the string
associated with the specified category for the new locale. If the
selection cannot be honored, the setlocale function returns a null
pointer and the program?s locale is not changed."

Note that neither C or POSIX defines any errors or sets errno or the
likes. It simply returns a null pointer.

In C you would typically start your program with a call like:

#include <locale.h>

int main(int argc, char *argv[]) {
	setlocale(LC_CTYPE, "");

	...
}

This will try to set the locale to what the native environment
specifies, but will not error out if the value, if any, it receives does
not map to a valid locale. It will return a null pointer if it cannot
set the locale. Execution continues and the locale is set to the default
"C".

Our current behaviour in Python does not adhere to these semantics. To
illustrate:

# Obvious non-existing locale
>>> from locale import setlocale, LC_CTYPE
>>> setlocale(LC_CTYPE, 'B')
Error: unsupported locale setting

# Valid locale, but not available on my system
>>> from os import getenv
>>> from locale import setlocale, LC_CTYPE
>>> getenv('LANG')
>>> 'cy_GB.UTF-8'
>>> setlocale(LC_CTYPE, '')
Error: unsupported locale setting

Neither Perl or PHP throw any error when setlocale() is passed an
invalid locale. Python is being unnecessarily disruptive by throwing an
error.

As such I think PyLocale_setlocale() in Modules/_localemodule.c needs to
be adjusted. Patch against trunk enclosed. This changes the semantics of
our current implementation to the following:

>>> from locale import setlocale, LC_CTYPE
>>> rv = setlocale(LC_CTYPE, 'B')
>>> type(rv)
<class 'NoneType'>
>>> rv = setlocale(LC_CTYPE, 'C')
>>> type(rv)
<class 'str'>
>>> rv
'C'

----------
Added file: http://bugs.python.org/file13843/locale.diff

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

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: [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 =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 00:07:57 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 02 May 2009 22:07:57 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
In-Reply-To: <1241300914.39.0.216667218535.issue1443504@psf.upfronthosting.co.za>
Message-ID: <49FCC411.9070806@v.loewis.de>


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

> If a pointer to a string is given for locale and the selection can be
> honored, the setlocale function returns a pointer to the string
> associated with the specified category for the new locale. If the
> selection cannot be honored, the setlocale function returns a null
> pointer and the program?s locale is not changed."
> 
> Note that neither C or POSIX defines any errors or sets errno or the
> likes. It simply returns a null pointer.

Still, this is considered as an error case.

> #include <locale.h>
> 
> int main(int argc, char *argv[]) {
> 	setlocale(LC_CTYPE, "");
> 
> 	...
> }
> 
> This will try to set the locale to what the native environment
> specifies, but will not error out if the value

Yes, but that's a bug in the C code, which fails to check the
return value of setlocale. The fact that the bug is wide-spread
doesn't make it any better.

> As such I think PyLocale_setlocale() in Modules/_localemodule.c needs to
> be adjusted

-1. Errors should never pass silently. That's the whole point of exceptions.

----------

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

From report at bugs.python.org  Sun May  3 00:26:02 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sat, 02 May 2009 22:26:02 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1241303162.85.0.83418488364.issue5201@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

The attached patch does fix this issue.

Concerning the specific example of LDFLAGS used here there is still and
issue with LDFLAGS being ignored by the buid for the shared modules, but
that is an other issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file13845/makevars.diff

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

From report at bugs.python.org  Sun May  3 00:44:46 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 02 May 2009 22:44:46 +0000
Subject: [issue5728] Support telling TestResult objects a test run has finished
In-Reply-To: <1239279324.74.0.826216289254.issue5728@psf.upfronthosting.co.za>
Message-ID: <1241304286.19.0.283219227956.issue5728@psf.upfronthosting.co.za>


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

Committed in revision 72225.

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

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

From report at bugs.python.org  Sun May  3 00:56:22 2009
From: report at bugs.python.org (Paul Hummer)
Date: Sat, 02 May 2009 22:56:22 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1241304982.88.0.665964103676.issue1054967@psf.upfronthosting.co.za>


Paul Hummer <paul at eventuallyanyway.com> added the comment:

I've been doing a review of this patch for the last few hours.  There
are a few issues that need to be taken care of in order for it to move
forward, and I'm currently working on them, in this order:

  1. Update the patch to the most recent svn.  The most current patch is
almost 5 years old.  I've ported it forward.
  2. Fix the unittests.  The patch is failing its unittests currently,
and so I'm fixing the unittests, and will be adding tests where there
may not be any coverage.
  3. Implement the suggestions made by alberanid and kbk, adding tests
where necessary.

  I've been chatting with jafo, and am willing to commit to maintaining
this code for the next few years, and am willing to sign the contributor
agreement in order to do so.  I don't particularly want to step on
anyone's toes, so if someone else is also working on this, I'm happy to
hand off what I've already been working on.

----------
nosy: +rockstar

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

From report at bugs.python.org  Sun May  3 01:52:21 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sat, 02 May 2009 23:52:21 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1241308341.37.0.480905152039.issue5201@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

Hmm, the patch isn't quite right yet.  When a $$ is present in the
makefile .parse_makefile() needs to return a single $.  I'm not sure yet
what needs to happen with the \ for the shell escape.

----------

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

From report at bugs.python.org  Sun May  3 02:34:44 2009
From: report at bugs.python.org (Henrique Baggio)
Date: Sun, 03 May 2009 00:34:44 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1241310884.8.0.0150390501587.issue1128@psf.upfronthosting.co.za>


Henrique Baggio <hnrqbaggio at gmail.com> added the comment:

Sorry, I don't know how create a patch, but just change the line with 

parts = file.split(".") to parts = os.path.splitext(file)

and the problem is fixed.

----------
nosy: +hnrqbaggio

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

From report at bugs.python.org  Sun May  3 02:55:51 2009
From: report at bugs.python.org (Henrique Baggio)
Date: Sun, 03 May 2009 00:55:51 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1241312151.28.0.72092935138.issue1128@psf.upfronthosting.co.za>


Henrique Baggio <hnrqbaggio at gmail.com> added the comment:

I create a patch using the os.path.splitext function.

----------
Added file: http://bugs.python.org/file13846/msilib.__init__.patch

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

From report at bugs.python.org  Sun May  3 03:05:00 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 03 May 2009 01:05:00 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241312700.26.0.136898674387.issue5311@psf.upfronthosting.co.za>


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

Ok, I added one final Feature that allows the user to specify an
alternate Python directory. (The PathEdit for specifying the directory
will only display if this Feature is set to be installed.)

I think this patch is pretty much ready to go in now. It could use a
review and some testing from folks on other kinds of machines, but I
think all the functionality is there now. (And no need for CustomAction
scripts! Yay!)

If at all possible, I'd like to get this into the Python 3.1 beta so
that we can have as many people as possible test this out on other
Windows machines.

----------
Added file: http://bugs.python.org/file13847/bdist_msi.patch

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

From report at bugs.python.org  Sun May  3 03:20:52 2009
From: report at bugs.python.org (tyoc)
Date: Sun, 03 May 2009 01:20:52 +0000
Subject: [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: <1241313652.58.0.823855092607.issue5908@psf.upfronthosting.co.za>


tyoc <zaz at alum.com> added the comment:

OK, here is a resume of the anterior.

I see clearly that it matter where I import the library (dont know if 
is a problem of the library or python). This time the thread doesnt 
end, will end when you hit CTRL+C in the terminal, for test this you 
need enabled accessibility.

Steps

1) run the code as is and see that it prints spot 0, 1 end is not wrote
2) uncomment the line of import pyatspi # import in the main thread and 
run again, see that it only print 0, it app is stuck inside 
pyatspi.Registry.registerEventListener(cb, 'focus')


[code start]---------------------------
import threading 
class thr(threading.Thread): 
    def __init__(self): 
        threading.Thread.__init__(self) 
#        import pyatspi # import in the main thread 
    def run(self): 
        def cb(eve): 
            print eve 
        import pyatspi # import here in the new thread 
        print 'spot 0' 
        pyatspi.Registry.registerEventListener(cb, 'focus') 
        print 'spot 1'
        pyatspi.Registry.start() 
        print 'End' 
  
t = thr() 
t.start() 
t.join() 
[code end]---------------------------



So at less for this library, it matter where you import the thing.

----------

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

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: [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 04:31:00 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 03 May 2009 02:31:00 +0000
Subject: [issue5559] IDLE Output Window 's goto fails when path has spaces
In-Reply-To: <1237951372.91.0.474657570766.issue5559@psf.upfronthosting.co.za>
Message-ID: <1241317860.31.0.326522491779.issue5559@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

r72227.

How's your test code coming?  A relative Win filename with leading 
spaces should be found even when there's a file of same name but no 
spaces.

----------
keywords: +26backport

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

From report at bugs.python.org  Sun May  3 04:53:36 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 03 May 2009 02:53:36 +0000
Subject: [issue1607951] mailbox.Maildir re-reads directory too often
Message-ID: <1241319216.83.0.490056458318.issue1607951@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Committed to trunk in rev. 72213.

Committed to py3k in rev. 72228.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Sun May  3 06:26:09 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 03 May 2009 04:26:09 +0000
Subject: [issue5850] Full example for emulating a container type
In-Reply-To: <1240795238.51.0.123083578346.issue5850@psf.upfronthosting.co.za>
Message-ID: <1241324769.77.0.632760628338.issue5850@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Maybe the documentation for other examples should be referenced then?

----------

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

From report at bugs.python.org  Sun May  3 06:27:29 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 03 May 2009 04:27:29 +0000
Subject: [issue5679] cleanUp stack for unittest
In-Reply-To: <1238788607.78.0.0557494613751.issue5679@psf.upfronthosting.co.za>
Message-ID: <1241324849.26.0.587045496778.issue5679@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Cool! Thanks for all of the hard work Michael :D.

----------

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

From report at bugs.python.org  Sun May  3 06:34:46 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 03 May 2009 04:34:46 +0000
Subject: [issue5738] multiprocessing example wrong
In-Reply-To: <1239483237.04.0.0741779763922.issue5738@psf.upfronthosting.co.za>
Message-ID: <1241325286.3.0.358200670025.issue5738@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Priorities shifted again at work, so I'll get around to this some time
around early June when I get an opportunity to implement multiprocessing
in my work code...

Thanks!

----------

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

From report at bugs.python.org  Sun May  3 09:04:48 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 07:04:48 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1241334288.88.0.632618403221.issue3959@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r72210 pep8-ified the test names.

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

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

From report at bugs.python.org  Sun May  3 09:07:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 May 2009 07:07:21 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241334441.64.0.193171835678.issue5902@psf.upfronthosting.co.za>


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

Actually I'd like to have some kind of convention mainly when the user
writes the encoding as a string, e.g. s.encode('utf-8'). Indeed, if the
encoding comes from a webpage or somewhere else it makes sense to have
some flexibility.

I think that 'utf-8' is the most widely used name for the UTF-8 codec
and it's not even mentioned in the table of the standard encodings. So
someone will use 'utf-8', someone else 'utf_8' and some users could even
pick one of the aliases, like 'U8'.

Probably is enough to add 'utf-8', 'iso-8859-1' and similar as
"preferred form" and explain why and how the codec names are normalized
and what are the valid aliases.

Regarding the ambiguity of 'UTF', it is not the only one, there's also
'LATIN' among the aliases of ISO-8859-1.

----------

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

From report at bugs.python.org  Sun May  3 09:14:16 2009
From: report at bugs.python.org (Claudio Canepa)
Date: Sun, 03 May 2009 07:14:16 +0000
Subject: [issue5559] IDLE Output Window 's goto fails when path has spaces
In-Reply-To: <1241317860.31.0.326522491779.issue5559@psf.upfronthosting.co.za>
Message-ID: <f5f20e3a0905022343t758c2f6dxc39db218701130a0@mail.gmail.com>


Claudio Canepa <ccanepacc at gmail.com> added the comment:

On Sat, May 2, 2009 at 11:31 PM, Kurt B. Kaiser <report at bugs.python.org>wrote:

>
> Kurt B. Kaiser <kbk at shore.net> added the comment:
>
> r72227.
>
> How's your test code coming?  A relative Win filename with leading
> spaces should be found even when there's a file of same name but no
> spaces.
>
> ----------

> keywords: +26backport
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5559>
> _______________________________________
>

Sorry for the delay, Kurt.
Test with rev 72227 , ok.

test cases:
(one space betwwen a and b , one before second tmp, one before first x)
Searching 'hello' in d:\tmp\*.tmp ...
d:\tmp\ xx.tmp: 1: hello # see woot.py:24 :24
d:\tmp\a b\ tmp\ xx.tmp: 1: hello # see woot.py:24 :24
d:\tmp\a b\ xx.tmp: 1: hello # see woot.py:24 :24
Found 3 hits.
( all three opens the correct file)

Same changing the target lines to stress the regex:
d:\tmp\ xx.tmp: 1: hello # see woot.py: 24:24
d:\tmp\a b\ tmp\ xx.tmp: 1: hello # see woot.py: 24:24
d:\tmp\a b\ xx.tmp: 1: hello # see woot.py: 24:24
Found 3 hits.
( all three opens the correct file)

Non absolute path:
 xx.py: 1: hello # see woot.py: 24:24
xx.py: 1: hello # see woot.py: 24:24
Found 2 hits.
( both opens the correct file)

others; not listed: ok.

Thanks for taking care Kurt.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5559>
_______________________________________
-------------- next part --------------
<br><br>
<div class="gmail_quote">On Sat, May 2, 2009 at 11:31 PM, Kurt B. Kaiser <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"><br>Kurt B. Kaiser &lt;<a href="mailto:kbk at shore.net">kbk at shore.net</a>&gt; added the comment:<br><br></div>r72227.<br><br>How&#39;s your test code coming? ??A relative Win filename with leading<br>spaces should be found even when there&#39;s a file of same name but no<br>
spaces.<br><br>----------</blockquote>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br>keywords: +26backport<br>
<div>
<div></div>
<div class="h5"><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue5559" target="_blank">http://bugs.python.org/issue5559</a>&gt;<br>
_______________________________________<br></div></div></blockquote></div>
<div><br>??</div>
<div>??</div>
<div>Sorry for the delay, Kurt.</div>
<div>Test with rev??72227 , ok.</div>
<div>??</div>
<div>test cases:</div>
<div>(one space betwwen a and b , one before second tmp, one before first x)</div>
<div>Searching &#39;hello&#39; in d:\tmp\*.tmp ...<br>d:\tmp\ xx.tmp: 1: hello # see woot.py:24 :24 <br>d:\tmp\a b\ tmp\ xx.tmp: 1: hello # see woot.py:24 :24 <br>d:\tmp\a b\ xx.tmp: 1: hello # see woot.py:24 :24 <br>Found 3 hits.<br>
( all three opens the correct file)</div>
<div>??</div>
<div>Same changing the target lines to stress the regex:</div>
<div>d:\tmp\ xx.tmp: 1: hello # see woot.py: 24:24 <br>d:\tmp\a b\ tmp\ xx.tmp: 1: hello # see woot.py: 24:24 <br>d:\tmp\a b\ xx.tmp: 1: hello # see woot.py: 24:24 <br>Found 3 hits.<br>( all three opens the correct file)</div>

<div>??</div>
<div>Non absolute path:</div>
<div>??xx.py: 1: hello # see woot.py: 24:24 <br>xx.py: 1: hello # see woot.py: 24:24 <br>Found 2 hits.<br>( both opens the correct file)</div>
<div>??</div>
<div>others; not listed: ok.</div>
<div>??</div>
<div>Thanks for taking care Kurt.</div>
<div><span lang="ES-MODERN"></span>??</div>
<div><span lang="ES-MODERN">--</span></div>
<div>ccanepa</div>

From report at bugs.python.org  Sun May  3 09:36:39 2009
From: report at bugs.python.org (tyoc)
Date: Sun, 03 May 2009 07:36:39 +0000
Subject: [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: <1241336199.83.0.878055960724.issue5908@psf.upfronthosting.co.za>


Changes by tyoc <zaz at alum.com>:


----------
title: I need to import the module in the same thread? -> I need to import the module in the same thread

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

From report at bugs.python.org  Sun May  3 10:49:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 May 2009 08:49:25 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241340565.14.0.316613402302.issue1443504@psf.upfronthosting.co.za>


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

Interestingly, my setlocale(3p) man page says:

"""
ERRORS
       No errors are defined.
"""

So isn't it debatable if returning the NULL pointer really is an error?

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

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

From report at bugs.python.org  Sun May  3 10:55:37 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 03 May 2009 08:55:37 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241340937.53.0.492171841511.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

I asked that as well on the POSIX/SUS list and Don Cragun responded with:

"If you make the last argument to setlocale() be a pointer to
unallocated memory, implementations would be allowed to set errno to
EFAULT and terminate the process with a core dump even when this section
says "No errors are defined."  An implementation could also set errno to
ENOENT (e.g., if the "B" locale wasn't known) or to EINVAL (e.g., if the
"B" locale existed but the LC_CTYPE portion of the locale was not in the
proper format).  That wording just means that the standard doesn't
require implementations to detect errors like these nor to report
specific error values for different possible errors."

On the subject whether or not returning a null pointer should be
considered he said:

"The standard is silent on this issue.
Why does it make any difference to an application?
If setlocale(LC_CTYPE, "B") returns a null pointer, the LC_CTYPE portion
of the locale was not changed.  If setlocale(LC_CTYPE, "B") does not
return a null pointer, the LC_CTYPE portion of the locale was
successfully changed."

I am just wondering why we want to be quite different from how many
other languages are approaching the issue. Sure enough, we can use a
try: construct, but it kind of defeats the principle of least
astonishment by being different from the rest on this issue.

----------

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

From report at bugs.python.org  Sun May  3 10:56:45 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 03 May 2009 08:56:45 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241341005.91.0.419791232831.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

On the subject whether or not returning a null pointer should be
considered he said:

->

On the subject whether or not returning a null pointer should be
considered an error he said:

----------

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

From report at bugs.python.org  Sun May  3 11:00:12 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 03 May 2009 09:00:12 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241341212.81.0.014896624252.issue1443504@psf.upfronthosting.co.za>


Changes by Jeroen Ruigrok van der Werven <asmodai at in-nomine.org>:


Removed file: http://bugs.python.org/file13843/locale.diff

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

From report at bugs.python.org  Sun May  3 11:00:49 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 03 May 2009 09:00:49 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241341249.57.0.550206264593.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Georg pointed out a mistake I introduced in my patch, updated now.

----------
Added file: http://bugs.python.org/file13849/locale.diff

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

From report at bugs.python.org  Sun May  3 11:04:25 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 03 May 2009 09:04:25 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241341465.9.0.584310702672.issue1443504@psf.upfronthosting.co.za>


Changes by Jeroen Ruigrok van der Werven <asmodai at in-nomine.org>:


Removed file: http://bugs.python.org/file13849/locale.diff

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

From report at bugs.python.org  Sun May  3 11:04:47 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 03 May 2009 09:04:47 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241341487.35.0.772527661879.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Really correct this time.

----------
Added file: http://bugs.python.org/file13850/locale.diff

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

From report at bugs.python.org  Sun May  3 11:51:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 May 2009 09:51:19 +0000
Subject: [issue5909] Segfault in typeobject.c
In-Reply-To: <1241298853.44.0.694039818999.issue5909@psf.upfronthosting.co.za>
Message-ID: <1241344279.33.0.814992472775.issue5909@psf.upfronthosting.co.za>


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

This doesn't look like a Python issue to me;  it also looks like it's 
nothing to do with ctypes, so I've unselected that from the components.

The bug may well be in gobjectmodule.c, which isn't part of core Python 
AFAIK.

Any chance you could narrow down the cause of the failure?

----------
assignee: theller -> 
components:  -ctypes
nosy: +marketdickinson -theller

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

From report at bugs.python.org  Sun May  3 13:44:10 2009
From: report at bugs.python.org (John Morton)
Date: Sun, 03 May 2009 11:44:10 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1241351050.85.0.713911807128.issue5907@psf.upfronthosting.co.za>


John Morton <jwm at angrymonkey.net.nz> added the comment:

While it's true that repr() methods cannot generally be expected to eval
back into an object of the same type, the old repr behaviour of the
struct_time object did effectively do so. Admittedly it was a kludge due
to the time module functions originally producing a tuple before the
advent of the struct_time type, but code that expected repr->eval
behaviour worked up to 2.5. It's also evident that who ever changed the
behaviour of time.struct_time.__repr__ intended that to sill be the
case, otherwise it would have produced a string of the form <time_struct
...>

So I would describe this as a bug, otherwise you'd have to call it an
undocumented behaviour change :-)

The question remains, how to fix it? Should the repr output change to
time.struct_time((tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec,
tm_wday, tm_yday, tm_isdst)) or implement the keyword argument form?

(Note: python3.0 shares this new behaviour)

----------
versions: +Python 3.0

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

From report at bugs.python.org  Sun May  3 13:46:26 2009
From: report at bugs.python.org (Gerald Britton)
Date: Sun, 03 May 2009 11:46:26 +0000
Subject: [issue5909] Segfault in typeobject.c
In-Reply-To: <1241298853.44.0.694039818999.issue5909@psf.upfronthosting.co.za>
Message-ID: <1241351186.46.0.599814167841.issue5909@psf.upfronthosting.co.za>


Gerald Britton <gerald.britton at gmail.com> added the comment:

This bug reports corresponds to one opened on Gnome:

http://bugzilla.gnome.org/show_bug.cgi?id=578419

According to the devs there:

"As far as I can tell this is a Python/C bug.  PyGObject is doing
everything by
the book, and it is Python that is giving us corrupted base objects.  I
debugged long and hard but was unable to fix a bug that just isn't
there, nor
was I able to figure out a workaround."

I sure don't want this to get into a finger-pointing battle!  All I know
is that I can reproduce this at will. If the backtrace is not enough to
narrow down the cause of failure, please let me know what you would
need.  I'll be glad to help solve the problem.

----------

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

From report at bugs.python.org  Sun May  3 13:50:29 2009
From: report at bugs.python.org (ayal baron)
Date: Sun, 03 May 2009 11:50:29 +0000
Subject: [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: [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 16:21:37 2009
From: report at bugs.python.org (Thomas Heller)
Date: Sun, 03 May 2009 14:21:37 +0000
Subject: [issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips
	instead of mipsel)
In-Reply-To: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>
Message-ID: <1241360497.76.0.505996830759.issue4305@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Tested myself, on a mipsel debian qemu instance.

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

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

From report at bugs.python.org  Sun May  3 17:15:43 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sun, 03 May 2009 15:15:43 +0000
Subject: [issue5379] Multicast example mcast.py is outdated and ugly
In-Reply-To: <1235699401.83.0.959623868909.issue5379@psf.upfronthosting.co.za>
Message-ID: <1241363743.75.0.587386793772.issue5379@psf.upfronthosting.co.za>


Philipp Hagemeister <phihag at phihag.de> added the comment:

Updated patch to use the new ipaddr module instead of the
platform-specific socket.inet_pton (unavailable on some platforms,
including Windows XP)
Updated formatting

----------
Added file: http://bugs.python.org/file13851/mcast-example.diff

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

From report at bugs.python.org  Sun May  3 17:15:51 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sun, 03 May 2009 15:15:51 +0000
Subject: [issue5379] Multicast example mcast.py is outdated and ugly
In-Reply-To: <1235699401.83.0.959623868909.issue5379@psf.upfronthosting.co.za>
Message-ID: <1241363751.43.0.120011937345.issue5379@psf.upfronthosting.co.za>


Changes by Philipp Hagemeister <phihag at phihag.de>:


Removed file: http://bugs.python.org/file13198/mcast-example.diff

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

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: [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 report at bugs.python.org  Sun May  3 17:36:24 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 03 May 2009 15:36:24 +0000
Subject: [issue5914] Add PyOS_string_to_double function to C API
In-Reply-To: <1241364435.9.0.132810257571.issue5914@psf.upfronthosting.co.za>
Message-ID: <1241364984.49.0.353723735713.issue5914@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This looks okay to me (although since it's not hooked up I haven't
tested it). I particularly like that it doesn't allow leading
whitespace, and that the caller no longer has to remember errno
(forgetting to set and/or test it have both caused me problems in the past).

Does the whitespace change cause any problems for any internal code? I
wouldn't think so, but I haven't looked at it.

As long as you're at it, I'd suggest deprecating PyOS_ascii_*.

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

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

From report at bugs.python.org  Sun May  3 18:15:46 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 03 May 2009 16:15:46 +0000
Subject: [issue3286] IDLE opens window too low on Windows
In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>
Message-ID: <1241367346.95.0.757223650336.issue3286@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

IDLE doesn't control window placement - that's left to Tk to handle.  
Hopefully it will get better with time.  Once you take control, you 
have to handle all the window placement, which is one of the things 
that window managers are expert at, supposedly.  You could try taking 
your issue to the Tcl/Tk devs.

I'm running 8.5 here on a netbook with XP and a 1024x800 screen.  I 
simply reduced the initial height to 33 using the Configure dialog.

Zooming the window height is also helpful.  Use the hotkey.  Some 
attempt to control position  by platform has been made in 
ZoomHeight.py, where you'll find some magic numbers.  

On Linux, some people have panels at the top, some at the bottom, some 
hide them, and some don't have any.  Maybe we'll look at this config 
again once we get the extension parameters on the Config dialog.  We 
could move some of those magic numbers to the config file.

----------
assignee:  -> kbk
nosy: +kbk
resolution:  -> wont fix
status: open -> closed

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 19:16:10 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 17:16:10 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
In-Reply-To: <1241340565.14.0.316613402302.issue1443504@psf.upfronthosting.co.za>
Message-ID: <49FDD155.90708@v.loewis.de>


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

> """
> ERRORS
>        No errors are defined.
> """
> 
> So isn't it debatable if returning the NULL pointer really is an error?

As Jeroen reports, this really means two different things
a) "no errors" really means "no errno codes". Whether or not
   an error may occur is an independent issue.
b) "are defined" really means that POSIX doesn't define any
   standard errno codes; the system may indeed still set errno
   (C99, 7.5p3)

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 19:20:24 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 17:20:24 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
In-Reply-To: <1241340937.53.0.492171841511.issue1443504@psf.upfronthosting.co.za>
Message-ID: <49FDD252.5080904@v.loewis.de>


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

> I am just wondering why we want to be quite different from how many
> other languages are approaching the issue.

Because we have exceptions, and they don't. Would you also propose
that open() should return None, just because fopen(3) returns NULL?

While it may be debatable whether applications care about the error
when passing "" as the locale, there is also the second case where
applications pass an explicit locale

  setlocale(locale.LC_ALL, "de_DE at euro")

When they do that, they surely want to be told if this actually
worked.

> Sure enough, we can use a
> try: construct, but it kind of defeats the principle of least
> astonishment by being different from the rest on this issue.

There is also the backwards compatibility issue: your change
will break existing code.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 19:31:03 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 17:31:03 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241351050.85.0.713911807128.issue5907@psf.upfronthosting.co.za>
Message-ID: <49FDD4D4.4040307@v.loewis.de>


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

> The question remains, how to fix it? 

Or whether to change it at all. It's hard to imagine that
applications may rely on that aspect of the behavior - they
have to use eval, after all.

----------

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

From report at bugs.python.org  Sun May  3 19:36:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 17:36:56 +0000
Subject: [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: <1241372216.49.0.847578529009.issue5913@psf.upfronthosting.co.za>


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

As for the "C:" behaviour, I think it is normal: you are not specifying
the path itself, only the drive letter, so it uses the current path in
the specified drive (which /is/ cwd if you are already running from C:,
but may be something else if running from another drive).

As for '' and b'', I think that ambiguity is bad and these values should
be prohibited by Python (ValueError comes to mind).

----------
nosy: +loewis, pitrou
priority:  -> high
stage:  -> test needed
versions:  -Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun May  3 19:44:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 17:44:14 +0000
Subject: [issue5910] kqueue for more than one event is broken.
In-Reply-To: <1241301488.84.0.663629523973.issue5910@psf.upfronthosting.co.za>
Message-ID: <1241372654.17.0.195329219776.issue5910@psf.upfronthosting.co.za>


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


----------
nosy: +christian.heimes

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

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


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

Thanks for the feedback!

Here's an updated patch that also deprecates PyOS_ascii_strtod and 
PyOS_ascii_atof and hooks up PyOS_string_to_double everywhere.  The 
documentation still needs proper markup, and I'll add some C-API tests.

----------
Added file: http://bugs.python.org/file13853/string_to_double_v2.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 19:46:00 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 17:46:00 +0000
Subject: [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: <1241372760.27.0.819132586835.issue5913@psf.upfronthosting.co.za>


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

Before anything is changed, I would first like to understand where the
difference comes from.

If it gives ENOENT on Unix, it should also give ENOENT on Windows
(rather than giving ValueError). In addition, it should also give what
open("")/open(b"") gives - as it really is the request to open the
directory named "". (disclaimer: I haven done any tests or code review yet)

----------

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

From report at bugs.python.org  Sun May  3 20:32:28 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 03 May 2009 18:32:28 +0000
Subject: [issue5914] Add PyOS_string_to_double function to C API
In-Reply-To: <1241364435.9.0.132810257571.issue5914@psf.upfronthosting.co.za>
Message-ID: <1241375548.76.0.634765631652.issue5914@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This looks okay to me, and passes the tests.

In PyOS_string_to_double, you can simplify it by using PyErr_Format
instead of printing into a buffer and using PyErr_SetString. Sorry I
didn't catch this earlier.

----------

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

From report at bugs.python.org  Sun May  3 20:58:58 2009
From: report at bugs.python.org (Fazal Majid)
Date: Sun, 03 May 2009 18:58:58 +0000
Subject: [issue5809] "No such file or directory" with framework build under
	MacOS 10.4.11
In-Reply-To: <1240329712.27.0.0341104214309.issue5809@psf.upfronthosting.co.za>
Message-ID: <1241377138.04.0.417917445199.issue5809@psf.upfronthosting.co.za>


Fazal Majid <python at sentfrom.com> added the comment:

I am experiencing the same problem with 2.6.2, whether using parallel
make or not, but 2.6.1. builds just fine.

----------
nosy: +majid

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

From report at bugs.python.org  Sun May  3 21:10:15 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 19:10:15 +0000
Subject: [issue5379] Multicast example mcast.py is outdated and ugly
In-Reply-To: <1235699401.83.0.959623868909.issue5379@psf.upfronthosting.co.za>
Message-ID: <1241377815.66.0.11003580452.issue5379@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks!  committed in r72237 & py3k r72238.

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

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

From report at bugs.python.org  Sun May  3 21:28:35 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 03 May 2009 19:28:35 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241378915.65.0.333946355728.issue5311@psf.upfronthosting.co.za>


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

A slightly improved patch, using DuplicateFile instead of storing a copy
of each file for each Python version. Should keep the size of the
resulting MSI similar to the size of the currently generated MSIs.

----------
Added file: http://bugs.python.org/file13854/bdist_msi.patch

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

From report at bugs.python.org  Sun May  3 21:28:49 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 03 May 2009 19:28:49 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241378929.4.0.433752434489.issue5311@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13847/bdist_msi.patch

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

From report at bugs.python.org  Sun May  3 21:46:58 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 19:46:58 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241380018.84.0.396020141555.issue5753@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

both the behavior change and PySys_SetArgvEx() with an additional
boolean parameter sounds good to me.

Some people may disagree about changing the default behavior.  So long
as its documented in the whatsnew I personally think it is fine.  But
would doing that require incrementing the API version number?

+1 on adding a PySys_SetArgvEx() in time for 3.1 (the clock is ticking
fast).

+0 on the existing API default change.

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

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

From report at bugs.python.org  Sun May  3 21:48:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 May 2009 19:48:23 +0000
Subject: [issue5724] 2.6.2c1 fails to pass test_cmath on Solaris10
In-Reply-To: <1239226094.42.0.345959405343.issue5724@psf.upfronthosting.co.za>
Message-ID: <1241380103.53.0.0376623213134.issue5724@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun May  3 22:12:07 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 03 May 2009 20:12:07 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241381527.6.0.210476183783.issue5311@psf.upfronthosting.co.za>


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

Ok, one last tiny update that makes sure TARGETDIR is always set to one
of the TARGETDIRX.Ys from a Feature that is actually selected.

I swear I'm done with this now. ;-)

----------
Added file: http://bugs.python.org/file13855/bdist_msi.patch

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

From report at bugs.python.org  Sun May  3 22:12:20 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 03 May 2009 20:12:20 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241381540.02.0.767064530643.issue5311@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13854/bdist_msi.patch

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

From report at bugs.python.org  Sun May  3 22:17:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 20:17:02 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241381822.43.0.896839095654.issue5753@psf.upfronthosting.co.za>


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

By the way, the advantage of a new function over a behaviour change is
that the new function could safely be backported to 2.6.3, since it is
also a "security fix".

----------

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

From report at bugs.python.org  Sun May  3 22:21:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 20:21:17 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241382077.18.0.167845070559.issue5753@psf.upfronthosting.co.za>


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


----------
nosy: +barry, benjamin.peterson
priority: critical -> release blocker
stage: test needed -> needs patch
versions: +Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun May  3 22:22:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 20:22:02 +0000
Subject: [issue5705] os.getpwent returns unsigned 32bit value,
	os.setuid refuses it
In-Reply-To: <1238971076.18.0.458968995084.issue5705@psf.upfronthosting.co.za>
Message-ID: <1241382122.33.0.993803753389.issue5705@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

release30-maint r72245 (its already been merged into py3k).

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 22:23:33 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:23:33 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241382213.17.0.505363382046.issue5311@psf.upfronthosting.co.za>


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

Can you kindly attach a demo MSI, to simplify review?

----------

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

From report at bugs.python.org  Sun May  3 22:27:32 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 03 May 2009 20:27:32 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241382452.37.0.226066687193.issue5311@psf.upfronthosting.co.za>


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

Here's an MSI generated for the argparse module.

----------
Added file: http://bugs.python.org/file13856/argparse-0.9.1.win32.msi

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

From report at bugs.python.org  Sun May  3 22:32:30 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 20:32:30 +0000
Subject: [issue1684] CGIHTTPServer does not chdir prior to executing the CGI
	script
In-Reply-To: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za>
Message-ID: <1241382750.27.0.559463282842.issue1684@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

yes the reporter is correct.

the suggested chdir happens in the subprocess.

however, that only works on posix systems:

windows currently uses popen2/3.  (see issue1535504 for another issue
with that).  switching to subprocess and passing in cwd would fix it.

and non-posix non-windows (what is that?) uses execfile to run the
script in process.  we can't fix that one, nor should be bother.  what
is a non-posix non-windows system that needs to run a cgi http server??

----------
assignee: christian.heimes -> gregory.p.smith
nosy: +gregory.p.smith

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

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


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

Thanks.  I've committed a version of this patch, with Eric's suggested 
PyErr_Format change, in r72248.

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

_______________________________________
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: [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 =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 22:42:42 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:42:42 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241383362.06.0.978696510879.issue5915@psf.upfronthosting.co.za>


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

http://codereview.appspot.com/52095

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May  3 22:52:49 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:52:49 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241383969.4.0.205864772567.issue5915@psf.upfronthosting.co.za>


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

Some notes, in addition to the PEP:

- the file system APIs have all stopped using et converters, and use O&
converters, with a new API function PyUnicode_FSConverter. This outputs
a bytes or bytearray object which needs to be released when done; if it
is a bytearray, the bytes also need to be locked when the GIL is released.

- to convert the environment successfully, initialization of the
filesystemddefaultencoding had to be moved up in the code.

- conversion of the command line arguments can't use codecs. Instead, it
uses the C library, hoping that their encoding is the same as the one
that we later determine as the file system encoding. With C99 mbrtowc,
it is possible to put utf8b escapes in the output; without that
function, every non-ASCII byte gets escaped if the CRT fails to convert
the entire string successfully.

- in the unlikely case that listdir still fails (if the file system
encoding cannot convert ASCII bytes sometimes), listdir now raises an
exception, to be consistent with the failure mode in all other places
where this problem may occur.

----------

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

From report at bugs.python.org  Sun May  3 23:11:54 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 03 May 2009 21:11:54 +0000
Subject: [issue3286] IDLE opens window too low on Windows
In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>
Message-ID: <1241385114.55.0.447521937488.issue3286@psf.upfronthosting.co.za>


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

When I shrank the initial height, tk starting randomizing the initial
placement so that it only occasionally puts the window too low.  I will
tolerate that.

It is a bug for a window manager to ignore the Taskbar; this is rare to
unique in my experience.  In fact, most Windows apps reopen at the size
and position closed.  But I am no longer bothered enough to find,
register with, and post to another tracker.  Thanks for explaining.

----------

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

From report at bugs.python.org  Sun May  3 23:16:00 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 03 May 2009 21:16:00 +0000
Subject: [issue3286] IDLE opens window too low on Windows
In-Reply-To: <1241385114.55.0.447521937488.issue3286@psf.upfronthosting.co.za>
Message-ID: <ac2200130905031415o6b1e40a1q7e7f32c49afa5938@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> It is a bug for a window manager to ignore the Taskbar; this is rare to
> unique in my experience. ?In fact, most Windows apps reopen at the size
> and position closed. ?But I am no longer bothered enough to find,
> register with, and post to another tracker. ?Thanks for explaining.

Actually we could change IDLE to tell Tk to display the window at the
last used position.

----------

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

From report at bugs.python.org  Sun May  3 23:41:41 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 May 2009 21:41:41 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241386901.69.0.882152046024.issue5915@psf.upfronthosting.co.za>


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

The calls to bytes2str are not checked in posixmodule.c.


http://codereview.appspot.com/52095/diff/1/5
File Include/unicodeobject.h (right):

http://codereview.appspot.com/52095/diff/1/5#newcode1254
Line 1254: The function is intended to be used for paths and file names
only
If these are only meant to be used internally during bootstrap, should
they have the _Py prefix?

http://codereview.appspot.com/52095/diff/1/10
File Lib/test/test_pep383.py (right):

http://codereview.appspot.com/52095/diff/1/10#newcode1
Line 1: from test import support
I'm not sure this deserves a whole new file. Couldn't UtfbTest go in
test_codecs and FileTests go in test_os?

http://codereview.appspot.com/52095/diff/1/10#newcode2
Line 2: import unittest, shutil, os, sys
PEP 8 says these should be on separate lines.

http://codereview.appspot.com/52095/diff/1/10#newcode33
Line 33: if os.name != 'win32':
Isn't os.name "nt" on Windows?

Also, you could skip this whole class on Windows by decorating the class
with @unittest.skipIf(sys.platform.startswith("win")).

http://codereview.appspot.com/52095/diff/1/10#newcode47
Line 47: f = open(self.bdir + b"/" + fn, "w")
Looks like a good place for os.path.join.

http://codereview.appspot.com/52095/diff/1/13
File Modules/posixmodule.c (right):

http://codereview.appspot.com/52095/diff/1/13#newcode547
Line 547: else if(PyByteArray_Check(o)) {
There's a small white space problem here.

http://codereview.appspot.com/52095/diff/1/13#newcode548
Line 548: if (lock && o->ob_type->tp_as_buffer->bf_getbuffer(o, NULL, 0)
< 0)
I believe you want PyObject_GetBuffer here.

http://codereview.appspot.com/52095/diff/1/13#newcode596
Line 596: bytes2str(name, 0));
What if byte2str returns NULL?

http://codereview.appspot.com/52095/diff/1/2
File Python/codecs.c (right):

http://codereview.appspot.com/52095/diff/1/2#newcode852
Line 852: if (!res)
This leaks "object".

http://codereview.appspot.com/52095/diff/1/2#newcode895
Line 895: return NULL;
This leaks "object".

http://codereview.appspot.com/52095

----------

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

From report at bugs.python.org  Mon May  4 00:00:42 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 22:00:42 +0000
Subject: [issue1684] CGIHTTPServer does not chdir prior to executing the CGI
	script
In-Reply-To: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za>
Message-ID: <1241388042.42.0.031646870911.issue1684@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi - non-posix / non-windows platforms could include alternate python
VMs that don't support fork, popen2 or subprocess.

----------
assignee: gregory.p.smith -> 

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

From report at bugs.python.org  Mon May  4 00:03:19 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sun, 03 May 2009 22:03:19 +0000
Subject: [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:06:12 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 May 2009 22:06:12 +0000
Subject: [issue3066] FD leak in urllib2
In-Reply-To: <1213009389.23.0.132424094421.issue3066@psf.upfronthosting.co.za>
Message-ID: <1241388372.02.0.257923900863.issue3066@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

not reproducable in head as stated.

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

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

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: [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 00:21:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 May 2009 22:21:29 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
In-Reply-To: <1241340937.53.0.492171841511.issue1443504@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0905031802430.3802@kimball.webabinitio.net>


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

On Sun, 3 May 2009 at 08:55, Jeroen Ruigrok van der Werven wrote:
> I am just wondering why we want to be quite different from how many
> other languages are approaching the issue. Sure enough, we can use a
> try: construct, but it kind of defeats the principle of least
> astonishment by being different from the rest on this issue.

Only if you imagine that the principal applies to expectations inherited
from other languages.  In a Python context, which is what the principle
actually refers to, it would be astonishing if the error were to be
silently ignored.

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

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

From report at bugs.python.org  Mon May  4 00:22:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 May 2009 22:22:07 +0000
Subject: [issue5913] On Windows os.listdir('') -> cwd and os.listdir(u'') ->
	C:\
In-Reply-To: <1241372216.49.0.847578529009.issue5913@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0905031809500.3802@kimball.webabinitio.net>


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

On Sun, 3 May 2009 at 17:36, Antoine Pitrou wrote:
> As for the "C:" behaviour, I think it is normal: you are not specifying
> the path itself, only the drive letter, so it uses the current path in
> the specified drive (which /is/ cwd if you are already running from C:,
> but may be something else if running from another drive).

It is normal behavior for Windows.  Try it with the 'dir' command
in a command window.  (That said, I have no idea, not being a
Windows user, how Windows decides what the 'current' directory
is on any given drive from any given context).

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

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

From =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May  4 00:58:05 2009
From: =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sun, 03 May 2009 22:58:05 +0000
Subject: [issue5108] Invalid UTF-8 ("%s") length in PyUnicode_FromFormatV()
In-Reply-To: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>
Message-ID: <1241391485.03.0.0334090045653.issue5108@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Checked in:
r72260 (trunk)
r72262 (release26-maint)
r72265 (py3k)
r72266 (release30-maint)

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

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

From report at bugs.python.org  Mon May  4 01:38:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 May 2009 23:38:23 +0000
Subject: [issue5108] Invalid UTF-8 ("%s") length in PyUnicode_FromFormatV()
In-Reply-To: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>
Message-ID: <1241393903.58.0.58730381449.issue5108@psf.upfronthosting.co.za>


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

> The problem with your patch is that it calls PyUnicode_DecodeUTF8() 
twice

I read your patch: storing the decoded string is the right way to do 
that, but i didn't noticed the "callresult stack".

> Could you test this new version to see if there's still a Valgrind 
report?

I will try to reproduce the crash using my Python fuzzer (Fusil). But 
it looks better (and valid).

Thanks.

----------

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

From report at bugs.python.org  Mon May  4 01:39:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 23:39:31 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241393971.73.0.81736007013.issue5753@psf.upfronthosting.co.za>


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

Here is a patch for trunk.

----------
Added file: http://bugs.python.org/file13860/setargvex.patch

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

From report at bugs.python.org  Mon May  4 01:41:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 23:41:43 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241394103.48.0.156332769298.issue5753@psf.upfronthosting.co.za>


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

Jan, would the new API be ok to you?

----------

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

From report at bugs.python.org  Mon May  4 01:48:29 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 May 2009 23:48:29 +0000
Subject: [issue1266570] PEP 349: allow str() to return unicode
Message-ID: <1241394509.94.0.213487467965.issue1266570@psf.upfronthosting.co.za>


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

PEP 349 was rejected because it breaks backward compatibility, eg. it 
breaks the assomption that str(u"x") converts unicode to byte string.

Python3 is the only good fix for all byte/character Python2 issues.

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

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

From report at bugs.python.org  Mon May  4 01:50:37 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 May 2009 23:50:37 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1241394637.59.0.044817778125.issue1602@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon May  4 01:51:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 May 2009 23:51:10 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1241394670.51.0.231281215582.issue1602@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon May  4 01:57:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 May 2009 23:57:05 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1241395025.21.0.697286406768.issue1602@psf.upfronthosting.co.za>


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

Yes, it is a Windows problem. There simply doesn't seem to be a true
Unicode codepage for command-line apps. Recommend closing.

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

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

From report at bugs.python.org  Mon May  4 02:01:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 00:01:15 +0000
Subject: [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 02:01:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 00:01:48 +0000
Subject: [issue3130] In some UCS4 builds,
	sizeof(Py_UNICODE) could end up being more than 4.
In-Reply-To: <1213695549.9.0.858416360908.issue3130@psf.upfronthosting.co.za>
Message-ID: <1241395308.65.0.16405325131.issue3130@psf.upfronthosting.co.za>


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

I like the idea of using uint16_t and uint32_t. Unicode 5.1 contains 
approximately 1 million of codes (and 100,000 characters), so 21 bits 
are already enough to use the full Unicode 5.1 standard (released in 
April 2009). Use more than 32 bits for an unicode character is wasting 
memory.

----------

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

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


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

Sorry, it also fails with "./python -m test.regrtest test_os
test_parser", so it's not caused by test_distutils.

----------
assignee: tarek -> 
title: test_parser crashes when run after test_distutils -> test_parser crashes when run after some other tests

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

From report at bugs.python.org  Mon May  4 02:24:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 00:24:06 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1241396646.47.0.250284769579.issue1298813@psf.upfronthosting.co.za>


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

The patch introduces a memory leak, canonicalize_file_name() returns a 
new allocated string which is not freed later.

----------

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

From report at bugs.python.org  Mon May  4 02:24:53 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 May 2009 00:24:53 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1241396693.12.0.94836673584.issue4751@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Committed with a couple refactorings in trunk r72267.  I also added a
test (basically checking for corruption that would occur if the locks
weren't working).

(I'll sort out any py3k vs trunk differences to make future change
merges easier).

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

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

From report at bugs.python.org  Mon May  4 02:58:46 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 May 2009 00:58:46 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1241398726.62.0.178132009238.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

With the implementation of issue5859 (py3k only), the only case where
this matters in NAN and INF. I'm going to address those in 3.1, and not
make any change for 2.x.

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

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

From report at bugs.python.org  Mon May  4 03:00:47 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 May 2009 01:00:47 +0000
Subject: [issue4482] 10e667.__format__('+') should return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1241398847.91.0.416912776522.issue4482@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

With the new PyOS_double_to_string, this issue largely goes away. There
are some remaining issues with commas, 'n' and the like. I'll address those.

----------

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

From report at bugs.python.org  Mon May  4 03:51:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 04 May 2009 01:51:17 +0000
Subject: [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: <1241401877.11.0.779938154857.issue5913@psf.upfronthosting.co.za>


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

I hope attached patch works.

>>> import os
>>> os.listdir("")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 3] ????????????????: ''
[36200 refs]
>>> os.listdir(u"")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 3] ????????????????: u''

# Error message says "Cannot find specified path"

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file13861/listdir_on_empty_path.patch

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

From report at bugs.python.org  Mon May  4 04:01:26 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 04 May 2009 02:01:26 +0000
Subject: [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: <1241402486.24.0.582529926029.issue5913@psf.upfronthosting.co.za>


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

For u"", os.listdir calls FindFirstFileW with u"\\*.*",
For "", os.listdir calls FindFirstFileA with "*.*".

The code before FindFirstFile[AW] is slightly different for empty path.

----------

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

From report at bugs.python.org  Mon May  4 04:17:58 2009
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 May 2009 02:17:58 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241403477.97.0.8994195086.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I've generated a new patch, attached.  I don't know why you had trouble
applying.  I tested this one with a clean tree and "patch -p1 < ..." and
it applied cleanly.  If it fails again, how about I upload the three
modified files?

I removed the extraneous changes.  I claim that the changes that remain
in ntpath are salient to the UNC changes, but feel free to call me on it
if I got that wrong.  (Or make a new patch as you have graciously
volunteered to do.)

I also amended splitdrive's UNC handling slightly; it now rejects
UNC-like paths that start with three slashes or have two slashes between
the host and mount point.  Thus neither "///computer/mountpoint/x" nor
"//computer//mountpoint/x" will be parsed as UNC paths.

----------
Added file: http://bugs.python.org/file13862/lch.ntpath.r72242.diff

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 06:18:47 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 04:18:47 +0000
Subject: [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: <1241410727.79.0.318090485942.issue5913@psf.upfronthosting.co.za>


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

Hirokazu, the patch looks fine, please apply to 2.7 and 3k.

I wouldn't backport it to 2.6/3.0, since it may break existing code.

----------
assignee:  -> ocean-city
resolution:  -> accepted

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 07:01:10 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 05:01:10 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <0016e645ab30f59f6404690f08af@google.com>


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

Reviewers: report_bugs.python.org, Benjamin,

Message:
Fixed in r72272

http://codereview.appspot.com/52095/diff/1/5
File Include/unicodeobject.h (right):

http://codereview.appspot.com/52095/diff/1/5#newcode1254
Line 1254: The function is intended to be used for paths and file names
only
On 2009/05/03 21:34:26, Benjamin wrote:
> If these are only meant to be used internally during bootstrap, should
they have
> the _Py prefix?

Perhaps. However, I only moved the declarations from a different part of
the file, so I feel renaming them is out of scope for this patch. Only
PyUnicode_FSConverter is new.

http://codereview.appspot.com/52095/diff/1/10
File Lib/test/test_pep383.py (right):

http://codereview.appspot.com/52095/diff/1/10#newcode1
Line 1: from test import support
On 2009/05/03 21:34:26, Benjamin wrote:
> I'm not sure this deserves a whole new file. Couldn't UtfbTest go in
test_codecs
> and FileTests go in test_os?

Done.

http://codereview.appspot.com/52095/diff/1/10#newcode2
Line 2: import unittest, shutil, os, sys
On 2009/05/03 21:34:26, Benjamin wrote:
> PEP 8 says these should be on separate lines.

Done.

http://codereview.appspot.com/52095/diff/1/10#newcode33
Line 33: if os.name != 'win32':
On 2009/05/03 21:34:26, Benjamin wrote:
> Isn't os.name "nt" on Windows?

class with
> @unittest.skipIf(sys.platform.startswith("win")).

Done. It's now in a non-Win32 section of test_os.

http://codereview.appspot.com/52095/diff/1/10#newcode47
Line 47: f = open(self.bdir + b"/" + fn, "w")
On 2009/05/03 21:34:26, Benjamin wrote:
> Looks like a good place for os.path.join.

Done.

http://codereview.appspot.com/52095/diff/1/13
File Modules/posixmodule.c (right):

http://codereview.appspot.com/52095/diff/1/13#newcode547
Line 547: else if(PyByteArray_Check(o)) {
On 2009/05/03 21:34:26, Benjamin wrote:
> There's a small white space problem here.

Sorry, I don't see it: what is the problem?

http://codereview.appspot.com/52095/diff/1/13#newcode548
Line 548: if (lock && o->ob_type->tp_as_buffer->bf_getbuffer(o, NULL, 0)
< 0)
On 2009/05/03 21:34:26, Benjamin wrote:
> I believe you want PyObject_GetBuffer here.

Done. Notice, however, the loss of symmetry with release_bytes, where an
equivalent API function does not appear to exist.

http://codereview.appspot.com/52095/diff/1/13#newcode596
Line 596: bytes2str(name, 0));
On 2009/05/03 21:34:26, Benjamin wrote:
> What if byte2str returns NULL?

It really shouldn't; bytes2str should only be applied to results of the
PyUnicode_FSConverter, which should have checked that the result is
either bytes or bytearray. I have now changed bytes2str to give a
FatalError otherwise.

http://codereview.appspot.com/52095/diff/1/2
File Python/codecs.c (right):

http://codereview.appspot.com/52095/diff/1/2#newcode852
Line 852: if (!res)
On 2009/05/03 21:34:26, Benjamin wrote:
> This leaks "object".

Done. Again :-(

http://codereview.appspot.com/52095/diff/1/2#newcode895
Line 895: return NULL;
On 2009/05/03 21:34:26, Benjamin wrote:
> This leaks "object".

Done.

Please review this at http://codereview.appspot.com/52095

Affected files:
   M     Doc/library/codecs.rst
   M     Doc/library/os.rst
   M     Include/unicodeobject.h
   A     Lib/test/test_pep383.py
   M     Modules/_io/fileio.c
   M     Modules/posixmodule.c
   M     Modules/python.c
   M     Objects/unicodeobject.c
   M     Python/codecs.c
   M     Python/pythonrun.c
   M     configure
   M     configure.in
   M     pyconfig.h.in

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 07:04:57 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 05:04:57 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241413497.36.0.0805841350471.issue5915@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13857/383.diff

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 07:07:04 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 05:07:04 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241413624.51.0.40991093151.issue5915@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file13863/383.diff

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

From report at bugs.python.org  Mon May  4 07:59:59 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 04 May 2009 05:59:59 +0000
Subject: [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: <1241416799.21.0.227162698522.issue5913@psf.upfronthosting.co.za>


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

Committed in r72273(trunk) and r72274(py3k).

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

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

From report at bugs.python.org  Mon May  4 08:12:49 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 04 May 2009 06:12:49 +0000
Subject: [issue4685] IDLE will not open (2.6.1 on WinXP pro)
In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za>
Message-ID: <1241417569.3.0.943675759632.issue4685@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Couple of comments.  First, your messages seem to indicate that 
you have both Python24 and Python26 installed.  Although that 
shouldn't cause problems, it might in your case. If you are no 
longer using Python24, please uninstall it.

First, open your Windows task manager and kill off any stale 
python processes.  If IDLE won't start with the subprocess, that's 
usually the problem.

Set IDLE to work with the subprocess, and try to reproduce your 
error.  If it's still there, kill off any resulting stale python 
processes.

Then, I'd really like to see the full error message if possible.

Open a Windows Command shell, and run this:

set >> test.log

c:\Python26\python -m idlelib.idle >> test.log 2>&1

Then reproduce the error, exit, and upload test.log to this 
tracker.

IDLE works much better if you use the subprocess!

----------
nosy: +kbk

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

From report at bugs.python.org  Mon May  4 08:21:59 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 May 2009 06:21:59 +0000
Subject: [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: <1241418119.42.0.0895500663113.issue5913@psf.upfronthosting.co.za>


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

> It is normal behavior for Windows.  Try it with the 'dir' command
> in a command window.  (That said, I have no idea, not being a
> Windows user, how Windows decides what the 'current' directory
> is on any given drive from any given context).

Yes, I tried to run cmd.exe and I did:

C:\> cd D:\foo
C:\> cd E:\foo
C:\> python

os.listdir('D:') and os.listdir('E:') then listed the content of D:\foo
and E:\bar. This is the correct behaviour, even if it's not documented.
The CWD is the one where Python has been launched, and apparently on the
other drives is the root folder by default, if it's not changed with the
cd command.

Thanks Hirokazu for the patch.

----------

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

From report at bugs.python.org  Mon May  4 09:45:03 2009
From: report at bugs.python.org (Fazal Majid)
Date: Mon, 04 May 2009 07:45:03 +0000
Subject: [issue1684] CGIHTTPServer does not chdir prior to executing the CGI
	script
In-Reply-To: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za>
Message-ID: <1241423103.19.0.348659143186.issue1684@psf.upfronthosting.co.za>


Fazal Majid <python at sentfrom.com> added the comment:

The problem is that in the current implementation there is no hook to
allow overriding any setup prior to exec, so the only way to produce the
standard UNIX behavior assumed by many scripts is to copy-paste the code
and patch it manually, which is very crude and defeats the whole idea of
including it in the standard library.

Part of the problem is that the CGI spec isn't properly documented. A
great many early Internet standards were slapdashedly written up by
Netscape on web sites that were dropped by AOL eventually.

----------

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

From report at bugs.python.org  Mon May  4 10:25:49 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 May 2009 08:25:49 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241256026.69.0.184003855831.issue5902@psf.upfronthosting.co.za>
Message-ID: <49FEA824.1080006@egenix.com>


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

On 2009-05-02 11:20, Georg Brandl wrote:
> Georg Brandl <georg at python.org> added the comment:
> 
> I don't think this is a good idea.  Accepting all common forms for
> encoding names means that you can usually give Python an encoding name
> from, e.g. a HTML page, or any other file or system that specifies an
> encoding.  If we only supported, e.g., "UTF-8" and no other spelling,
> that would make life much more difficult.  If you look into
> encodings/__init__.py, you can see that throwing out all
> non-alphanumerics is a conscious design choice in encoding name
> normalization.
> 
> The only thing I don't know is why "utf" is an alias for utf-8.
> 
> Assigning to Marc-Andre, who implemented most of codecs.

-1 on making codec names strict.

The reason why we have to many aliases is to enhance compatibility
with other software and data, not to encourage use of these aliases
in Python itself.

----------

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

From report at bugs.python.org  Mon May  4 10:32:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 May 2009 08:32:39 +0000
Subject: [issue3130] In some UCS4 builds,
	sizeof(Py_UNICODE) could end up being more than 4.
In-Reply-To: <1213695549.9.0.858416360908.issue3130@psf.upfronthosting.co.za>
Message-ID: <1241425959.84.0.475656676448.issue3130@psf.upfronthosting.co.za>


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

> We'd have to add an AC_TYPE_INT32_T and AC_TYPE_INT16_T check to
> configure:

AC_TYPE_INT32_T should already be there.  See also the code in
pyport.h that #defines HAVE_INT32_T and PY_INT32_T, and the
corresponding bits of PC/pyconfig.h.

It was recently pointed out that there are some issues with these
definitions when using a C++ compiler instead of a C compiler, since
then INT32_MAX is undefined.  (See the footnote to 7.18.2, para.1 of
C99.)

----------
nosy: +marketdickinson

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

From report at bugs.python.org  Mon May  4 10:36:39 2009
From: report at bugs.python.org (Vaibhav Mallya)
Date: Mon, 04 May 2009 08:36:39 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1241426199.72.0.763398379939.issue5906@psf.upfronthosting.co.za>


Vaibhav Mallya <mallyvai at umich.edu> added the comment:

I understand pakal's line of reasoning. The term 'daemon' in the general
Unix sense has a specific meaning that is at odds with the
multiprocessing module's usage of 'daemon'. Clarification would be
useful, I feel, especially if an outright rename of that part of the API
is out of the question.

----------
nosy: +mallyvai

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

From report at bugs.python.org  Mon May  4 10:40:05 2009
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 May 2009 08:40:05 +0000
Subject: [issue5630] Create alternative CObject API that is safe and clean
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1241426405.49.0.92701894717.issue5630@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Updated patch based on impressively thorough Rietveld feedback from
Benjamin Peterson.  Thanks, Benjamin!

This patch should not be considered final; we already know the API
documentation in the comments in Include/pycapsule.h needs to change
(somehow).

----------
Added file: http://bugs.python.org/file13864/lch.capsule.r72270.diff

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

From report at bugs.python.org  Mon May  4 10:43:30 2009
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 May 2009 08:43:30 +0000
Subject: [issue5880] Remove unneeded "context" pointer from getters and setters
In-Reply-To: <1241021724.62.0.808491876443.issue5880@psf.upfronthosting.co.za>
Message-ID: <1241426610.71.0.558933409929.issue5880@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Mark Dickinson: no extension module would ever *need* it.  One could
reproduce the functionality with stub intermediary functions, as follows:

PyObject *my_getter_with_context(PyObject *self, void *context) {
  /* ... /
}

PyObject *my_getter_A(PyObject *self) {
  return my_getter_with_context(self, "A");
}


PyObject *my_getter_B(PyObject *self) {
  return my_getter_with_context(self, "B");
}

/* etc. */

The body of Python extension code shows that this facility is rarely
needed.  And folks that need it can roll their own.

It's a minor thing, but I think it's worth doing, if we're willing to
break compatibility in this way.

Anyway, I'm gonna float it on python-dev.

----------

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

From report at bugs.python.org  Mon May  4 10:57:52 2009
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 May 2009 08:57:52 +0000
Subject: [issue5880] Remove unneeded "context" pointer from getters and setters
In-Reply-To: <1241021724.62.0.808491876443.issue5880@psf.upfronthosting.co.za>
Message-ID: <1241427472.13.0.941928578145.issue5880@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Oh, and, I looked at pyephem.  It uses the context field to... store an
integer.  In this case, the offset in a structure where it's going to
pull out a value (float or double).  This code would probably be clearer
if forced to make do without the "closure".

----------

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

From report at bugs.python.org  Mon May  4 11:20:24 2009
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 04 May 2009 09:20:24 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't be
	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1241428824.52.0.880315628458.issue5504@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Hm, I don't see any problems with current Python trunk or the
release26-maint branch, on a Fedora 10 system.

----------

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

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: [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 12:42:35 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 10:42:35 +0000
Subject: [issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29
Message-ID: <1241433755.39.0.503081724717.issue1054943@psf.upfronthosting.co.za>


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

Here is a patch fixing Unicode issue "PR29", I used the testcases 
given in http://www.unicode.org/review/pr-29.html

----------
keywords: +patch
Added file: http://bugs.python.org/file13865/unicode_pr29.patch

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

From report at bugs.python.org  Mon May  4 13:07:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 11:07:09 +0000
Subject: [issue4425] UTF7 encoding of slash (character 47) is incorrect
In-Reply-To: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
Message-ID: <1241435229.05.0.652986026618.issue4425@psf.upfronthosting.co.za>


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

I think that we can merge this issue with #4426.

----------
resolution:  -> duplicate

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

From report at bugs.python.org  Mon May  4 13:07:14 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 11:07:14 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241435234.36.0.314376899056.issue4426@psf.upfronthosting.co.za>


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

Copy of msg76404 from duplicate issue (#4425):
----
'/'.encode('utf7') returns '+AC8-'.  It should return '/'.  See RFC 
2152.

'/'.decode('utf7') raises an exception (this is a special case of a
general problem with UTF-7 decoding, which I will report as a separate 
bug).
----

----------

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

From report at bugs.python.org  Mon May  4 13:07:18 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 11:07:18 +0000
Subject: [issue4425] UTF7 encoding of slash (character 47) is incorrect
In-Reply-To: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
Message-ID: <1241435238.56.0.143148862067.issue4425@psf.upfronthosting.co.za>


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


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

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

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


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

Here's a patch, that also changed complex formatting in the same way.

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

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

From report at bugs.python.org  Mon May  4 13:39:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 May 2009 11:39:06 +0000
Subject: [issue1588] str.format() wrongly formats complex() numbers (Py30a2)
In-Reply-To: <1197379851.58.0.0476028374566.issue1588@psf.upfronthosting.co.za>
Message-ID: <1241437146.28.0.725544653638.issue1588@psf.upfronthosting.co.za>


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

> Yes, this is a separate issue.

Thanks.  See issue 5920.

----------

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

From report at bugs.python.org  Mon May  4 14:00:51 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 12:00:51 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241438451.3.0.802361152379.issue4426@psf.upfronthosting.co.za>


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

I updated the patch to python trunk. I was hard because "patch -p1" 
failed at many places, so please double check the updated patch.

Changes from utf7patch:
 * I removed the test "c >=0" in DECODE_DIRECT(c) because c type 
is "Py_UNICODE" and the type is always unsigned (right?)
 * I added "shiftOutStart = p;" at the beginning of 
PyUnicode_DecodeUTF7Stateful() to fix the gcc warning reported by 
pitrou.
 * I fixed the failing test in test_unicode.py (also reported by 
pitrou)
 * I added the tests listed in msg76414 (by nick)

I didn't read the UTF-7 encoder or decoder code. I just updated the 
patch.

----------
Added file: http://bugs.python.org/file13867/issue4426.patch

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

From report at bugs.python.org  Mon May  4 14:02:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 12:02:11 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241438531.14.0.737575884761.issue4426@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13867/issue4426.patch

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

From report at bugs.python.org  Mon May  4 14:02:14 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 04 May 2009 12:02:14 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1241438534.31.0.188829767068.issue1054967@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

Thanks for your efforts. I don't think you are stepping on anyone's toes
when picking up an issue that was unsolved for almost 5 years :-)

Please post patches to this bug for review/comments/help/whatever

----------

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

From report at bugs.python.org  Mon May  4 14:02:50 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 12:02:50 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241438570.18.0.932125708897.issue4426@psf.upfronthosting.co.za>


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

(oops, i stripped spaces in my last patch)

----------
Added file: http://bugs.python.org/file13868/issue4426.patch

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

From report at bugs.python.org  Mon May  4 14:25:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 12:25:45 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <0016e64616e6d0d92e04691542e8@google.com>


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

A couple of really small things.

http://codereview.appspot.com/52095/diff/30/1013
File Lib/test/test_codecs.py (right):

http://codereview.appspot.com/52095/diff/30/1013#newcode1545
Line 1545: b"foo\xa5bar")
You decode with iso-8859-3 but encode with iso-8859-4. Is it intended?

http://codereview.appspot.com/52095/diff/30/1014
File Lib/test/test_os.py (right):

http://codereview.appspot.com/52095/diff/30/1014#newcode704
Line 704: filenames = [b'foo\xf6bar', b'foo\xf6bar']
Is my sight bad, or is this twice the same filename?

http://codereview.appspot.com/52095/diff/30/1016
File Modules/python.c (right):

http://codereview.appspot.com/52095/diff/30/1016#newcode47
Line 47: /* Try conversion with mbsrtwocs (C99), and escape
non-decodable bytes. */
Typo: s/mbsrtwocs/mbrtowc/

http://codereview.appspot.com/52095

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

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

From report at bugs.python.org  Mon May  4 14:36:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 12:36:42 +0000
Subject: [issue3446] center,
	ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1241440602.93.0.49211908104.issue3446@psf.upfronthosting.co.za>


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

haypo> About Python3, bytes.center accepts unicode as second argument,
haypo> which is an error for me

Ok, it's fixed thanks by r71013 (issue #5499).

----------

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

From report at bugs.python.org  Mon May  4 14:38:31 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 12:38:31 +0000
Subject: [issue3446] center,
	ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1241440711.51.0.504640823135.issue3446@psf.upfronthosting.co.za>


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

This issue only concerns Python 2.x, Python 3.x has the right 
behaviour: it disallow mixing bytes with characters.

----------
versions: +Python 2.7 -Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Mon May  4 14:58:28 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 12:58:28 +0000
Subject: [issue3446] center,
	ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1241441908.38.0.732899725763.issue3446@psf.upfronthosting.co.za>


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

The question is why str.{ljust,rjust,center} doesn't accept unicode 
argument, whereas unicode.{ljust,rjust,center} accept ASCII string. 
Other string methods accept unicode argument, like str.count() (encode 
the unicode string to bytes using utf8 charset).

To be consistent with other string methods, str.{ljust,rjust,center} 
should accept unicode string and convert them to byte string using 
utf8, like str.count does. But I hate such implicit conversion (I 
prefer Python3 way: disallow mixing bytes and characters), so I will 
not contribute to such patch.

Can you write such patch?

--

str.{ljust,rjust,center} use PyArg_ParseTuple(args, "n|c:...", ...) 
and getarg('c') which only accepts a string of 1 byte.

unicode.{ljust,rjust,center} use PyArg_ParseTuple(args, "n|
O&:...", ..., convert_uc, ...) where convert_uc looks something like:

  def convert_uc(o):
     try:
        u = unicode(o)
     except:
        raise TypeError("The fill character cannot be converted to 
Unicode")
     if len(u) != 1:
        raise TypeError("The fill character must be exactly one 
character long"))
     return u[0]

convert_uc() accepts an byte string of 1 ASCII.

string_count() uses PyArg_ParseTuple(args, "O...", ...) and then test 
the substring type.

----------

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

From report at bugs.python.org  Mon May  4 15:17:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 13:17:36 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241443056.15.0.497696988883.issue4426@psf.upfronthosting.co.za>


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

A quick comment on the patch: it seems to invert (quite futily I'd say)
the meaning of the arguments given to PyUnicode_EncodeUTF7, which is an
incompatible API change.
I'm in favour of reworking this patch in order to keep the original API.
If I'm not mistaken, it's just a matter of using the boolean complement
of these two arguments (encodeSetO, encodeWhiteSpace) inside the body of
PyUnicode_EncodeUTF7.

----------

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

From report at bugs.python.org  Mon May  4 15:52:32 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 04 May 2009 13:52:32 +0000
Subject: [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 =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May  4 15:54:37 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: Mon, 04 May 2009 13:54:37 +0000
Subject: [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: <1241445277.62.0.443433662052.issue5900@psf.upfronthosting.co.za>


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

what about adding 'GNULD' into sysconfig.customize_compiler too, so it
can be set using os.environ as well, not only in the Makefile

----------

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

From report at bugs.python.org  Mon May  4 15:59:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 May 2009 13:59:23 +0000
Subject: [issue5724] 2.6.2c1 fails to pass test_cmath on Solaris10
In-Reply-To: <1239226094.42.0.345959405343.issue5724@psf.upfronthosting.co.za>
Message-ID: <1241445563.2.0.146897097811.issue5724@psf.upfronthosting.co.za>


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

Applied in r72275.  I've also applied the same changes to the
release30-maint branch in r72277.

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

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May  4 16:07:58 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: Mon, 04 May 2009 14:07:58 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1241446078.57.0.999008385553.issue5572@psf.upfronthosting.co.za>


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

> May be I miss something but I could not found why distutils 
> has to use LIBS to link a module.

It doesn't right now, but depending on the extension you want to build,
you might want to configure it and make sure it is passed to the compiler.

About the patch:

is there a particular reason why you have changed the call to
'set_library' into calls to 'add_library' in build_ext in your patch ?

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

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

From report at bugs.python.org  Mon May  4 16:11:55 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 04 May 2009 14:11:55 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1241446315.21.0.423736967248.issue5906@psf.upfronthosting.co.za>


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

I'm more than familiar with the Unix meaning of Daemon - and the API will 
*not* be changed or renamed.

----------

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May  4 16:14:40 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: Mon, 04 May 2009 14:14:40 +0000
Subject: [issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for
	C++"
In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
Message-ID: <1241446480.24.0.976103775963.issue5755@psf.upfronthosting.co.za>


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

I could work on a patch for this, by checking the compiler, if I get
some feedback from the matplotlib guys in this issue here

----------

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

From report at bugs.python.org  Mon May  4 16:29:51 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 14:29:51 +0000
Subject: [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: [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 17:02:49 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 04 May 2009 15:02:49 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241449369.3.0.461378477075.issue5923@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Just to see what I've changed:

The unified diff from version 1.0 ( Revision 69847 )
to the proposed version 1.1b

(Should result in version 1.1 'final'ly)

----------
keywords: +patch
Added file: http://bugs.python.org/file13871/turtle30_to_31.diff

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

From report at bugs.python.org  Mon May  4 17:21:39 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 04 May 2009 15:21:39 +0000
Subject: [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: <1241450499.02.0.438615230957.issue5900@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

I'm not convinced that would help much.  The GNULD variable in the
makefile is for when the default linker is used.  If you change that by
using LDSHARED then you're probably not going to be using --rpath but
LDFLAGS to configure it the way you want.

If anything maybe using configure/Makefile to detect if GNU ld is used
is wrong just for the case they use LDSHARED (I didn't think of this
before), since then they can use LDSHARED and --rpath and get misterious
failures.  But it seems a lot more complicated to do, LDSHARED can be
set to something like "cc -shared" (the default) in which case we can't
use -V and assume it's a non-GNU ld if we don't get "GNU" back.  So we'd
have to try and detect if LDSHARED is set to a compiler or a linker,
then try to find which linker gets invoked etc.  A lot more complicated
and way more possibilities then I can test.

I'd argue that when someone uses LDSHARED they should be using LDFLAGS
intead of --rpath, they obviously know what they are doing.  --rpath is
there if you want to use the environment Python was compiled in to build
an extension module with a RPATH/RUNPATH in.

----------

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

From report at bugs.python.org  Mon May  4 17:45:25 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 May 2009 15:45:25 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1241451925.16.0.351447888591.issue3244@psf.upfronthosting.co.za>


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


----------
assignee:  -> barry
nosy: +barry

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

From report at bugs.python.org  Mon May  4 17:48:26 2009
From: report at bugs.python.org (Lisandro Dalcin)
Date: Mon, 04 May 2009 15:48:26 +0000
Subject: [issue5630] Create alternative CObject API that is safe and clean
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1241452106.51.0.245975074943.issue5630@psf.upfronthosting.co.za>


Lisandro Dalcin <dalcinl at gmail.com> added the comment:

In Doc/c-api/capsule.rst, you wrote

.. cfunction:: int PyCapsule_Import(const char* name, int no_block)

but it should be:

.. cfunction:: void* PyCapsule_Import(const char* name, int no_block)

Additionally, you wrote "disambugate" in many places.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 18:18:41 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 16:18:41 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241453921.97.0.89326949564.issue5311@psf.upfronthosting.co.za>


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

The patch looks fine so far, please apply to trunk and 3k. As this is a
new feature, I think backporting it is not appropriate.

I believe that the support for (pre)install scripts is incorrect; I
would expect that each such script should be executed once per version
for which the package is installed. However, this can be fixed later;
for the moment, it would be good enough to warn at packaging time that
scripts may not work for multi-version packages.

You can also consider providing "Change" installation, allowing the user
to selectively add a package to a python version after that python
version is installed (or to remove it before the python version gets
removed). To do so, just add an option to the MaintenanceTypeDlg that
forks into the feature selection dialog, with the standard INSTALL action.

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

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

From report at bugs.python.org  Mon May  4 18:34:36 2009
From: report at bugs.python.org (Nick Barnes)
Date: Mon, 04 May 2009 16:34:36 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241454876.17.0.420518395144.issue4426@psf.upfronthosting.co.za>


Nick Barnes <Nick.Barnes at pobox.com> added the comment:

This was my first contribution to Python.  I don't know what the rules
are on changing the arguments of an internal function such as
PyUnicode_EncodeUTF7().  Since I was rewriting the whole function
anyway, I tried to give it arguments which made more sense with respect
to the defining RFC.  If you want us to revert to the original meanings
of these arguments (so the third argument means "use base-64 encoding
for characters in set O", and not "use direct encoding for characters in
set O"), please can we have better names for them?

The name "encodeSetO" was meaningless: the function encodes *all* the
characters in the string.  What the argument specifies is whether the
"set O" characters are self-encoded or base-64 encoded.  So maybe it
should be called "base64SetO".

Ditto for the "encodeWhiteSpace" name.

Here's a trunk patch with the meaning of those parameters reverted, and
better names.

----------
Added file: http://bugs.python.org/file13872/python-unicode-trunk-patch

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

From report at bugs.python.org  Mon May  4 18:46:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 04 May 2009 16:46:41 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1241455601.86.0.318129801168.issue1128@psf.upfronthosting.co.za>


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

The current patch is not correct, because os.path.splitext returns the
extension with the leading dot.

Here is another patch that simplifies the code (os.path.splitext is
guaranteed to return two strings)
It also adds the first unit test for msilib.

There is an unresolved issue: what is make_short('foo.2.txt') supposed
to return? FOO.2.TXT or FOO~1.TXT ?

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file13873/msilib-2.patch

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

From report at bugs.python.org  Mon May  4 18:59:44 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 16:59:44 +0000
Subject: [issue5919] pygettext documentation
In-Reply-To: <1241433644.84.0.826076454986.issue5919@psf.upfronthosting.co.za>
Message-ID: <1241456384.4.0.664597217734.issue5919@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl

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

From report at bugs.python.org  Mon May  4 19:01:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 17:01:24 +0000
Subject: [issue5921] PEP 362 can be marked as finished?
In-Reply-To: <1241445151.97.0.361648348921.issue5921@psf.upfronthosting.co.za>
Message-ID: <1241456484.22.0.969430680371.issue5921@psf.upfronthosting.co.za>


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

I fail to see how that relates to function signature objects... the
annotation PEP is 3107, and that is marked as final.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Mon May  4 19:03:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 17:03:17 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241456597.13.0.705362667592.issue5923@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis

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

From report at bugs.python.org  Mon May  4 19:04:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 17:04:56 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241456696.27.0.0946656062216.issue5902@psf.upfronthosting.co.za>


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

So, do you also think "utf" and "latin" should stay?

----------

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

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


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

You're right.  I got them mixed up.  Please disregard.  I'm just having
that kind of day.  :-)

----------

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

From report at bugs.python.org  Mon May  4 19:06:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 17:06:42 +0000
Subject: [issue5921] PEP 362 can be marked as finished?
In-Reply-To: <1241445151.97.0.361648348921.issue5921@psf.upfronthosting.co.za>
Message-ID: <1241456802.93.0.529779544916.issue5921@psf.upfronthosting.co.za>


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

I think I know what you mean :)

----------

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

From report at bugs.python.org  Mon May  4 19:47:14 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 04 May 2009 17:47:14 +0000
Subject: [issue5572] distutils ignores the LIBS configure env var
In-Reply-To: <1241446078.57.0.999008385553.issue5572@psf.upfronthosting.co.za>
Message-ID: <43aa6ff70905041047p2fcff101l5c5bf46e89142c2d@mail.gmail.com>


Collin Winter <collinw at gmail.com> added the comment:

2009/5/4  <"Tarek Ziad? <report at bugs.python.org>"@psf.upfronthosting.co.za>:
> About the patch:
>
> is there a particular reason why you have changed the call to
> 'set_library' into calls to 'add_library' in build_ext in your patch ?

Yes. It seems like the proper thing to do is to merge the global LIBS
and the module-specific libraries (via add_library()), rather than
having one override the other (set_library()).

----------

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

From report at bugs.python.org  Mon May  4 19:49:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 17:49:39 +0000
Subject: [issue1566260] Better order in file type descriptions
Message-ID: <1241459379.73.0.5337185486.issue1566260@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

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

From report at bugs.python.org  Mon May  4 20:06:34 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 04 May 2009 18:06:34 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1241460394.57.0.740915038867.issue5902@psf.upfronthosting.co.za>


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

Well, there are multiple UTF encodings, so no to "utf".

Are there multiple Latin encodings? Not in Python 2.6.2 under those names.

I'd probably insist on names that are strictish(?), ie correct, give or
take a '-' or '_'.

----------

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

From report at bugs.python.org  Mon May  4 20:16:25 2009
From: report at bugs.python.org (Henrique Baggio)
Date: Mon, 04 May 2009 18:16:25 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1241460985.27.0.177406180807.issue1128@psf.upfronthosting.co.za>


Henrique Baggio <hnrqbaggio at gmail.com> added the comment:

@Amaury,

Sorry my mistake. I forgot splitext returns a tuple. =/

About your question, if the file name has less then 8 characters, then 
the function don't change it. Else, it return tha name with 8 chars.

e.g., make_short(foo.2.txt) returns FOO.2.TXT
and make_short(foo.longer_name.txt) returns FOO.LO~1.TXT

----------

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

From report at bugs.python.org  Mon May  4 20:22:32 2009
From: report at bugs.python.org (Anthony Tuininga)
Date: Mon, 04 May 2009 18:22:32 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241461352.47.0.169239110253.issue5311@psf.upfronthosting.co.za>


Anthony Tuininga <anthony.tuininga at gmail.com> added the comment:

One additional suggestion: allow the packager to specify what the
minimum Python version is. Otherwise, you might have a package that
enables installation for Python 2.3 and 2.4 when the maintainer has
already stated that Python 2.5 is the minimum version supported.
Otherwise, looks great.

----------
nosy: +atuining

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

From report at bugs.python.org  Mon May  4 20:25:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 18:25:19 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241461519.08.0.554576561937.issue4426@psf.upfronthosting.co.za>


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

Thanks for the update. Functions like PyUnicode_EncodeUTF7() are part of
the public C API, therefore their semantics can't be changed lightly.
The patch looks ok to me, apart from minor style issues.

----------
assignee:  -> pitrou
resolution:  -> accepted
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Mon May  4 20:49:10 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 May 2009 18:49:10 +0000
Subject: [issue5920] Confusing float formatting for empty presentation type.
In-Reply-To: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>
Message-ID: <1241462950.59.0.197463137017.issue5920@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

About your patch: Wouldn't it make more sense to switch to type 's',
with a precision of 0, so as to use the same logic that float_str uses?
I realize it's the same result, but if we're making the point that we
want to match float_str, it makes sense to me to use the same logic so
you don't have to walk through the code to figure it out.

Or, also switch float_str to use 'g' with a precision of
PyFloat_STR_PRECISION, and get rid of 's' altogether. But maybe we
should do that as a separate step, after this change.

----------

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

From report at bugs.python.org  Mon May  4 20:54:00 2009
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 04 May 2009 18:54:00 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241463240.49.0.377863861559.issue5311@psf.upfronthosting.co.za>


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

@martin: 
Thanks! Do I need to do something special to make the merging work
right? Or do I just apply the patch separately to the trunk and the py3k
branche?

Good point about the install script - I think the condition needs to be
("&Python%s=3" % ver) instead of "NOT Installed". I'll use this approach
when I apply the patch, but clearly this needs some testing by folks
that use install scripts either way. I didn't worry much about the
pre-install script, since finalize_options() already throws an exception
saying that isn't supported

I'll open a new issue for support for a "Change" installation. This is
one of the nice things that treating Python versions as features allows,
I just haven't had time to look into it yet.

@anthony:
Allowing a minimum version to be set sounds like a nice feature. Could
you open a new feature request?

----------

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

From report at bugs.python.org  Mon May  4 20:59:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 18:59:12 +0000
Subject: [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1241463552.98.0.596590440604.issue4426@psf.upfronthosting.co.za>


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

Committed in r72283 and r72285. Thanks!

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

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

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: [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:07:48 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 04 May 2009 19:07:48 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1241464068.78.0.992022168883.issue5906@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I guess we all agree on the fact that a renaming of the API would be
highly disproportionate ;-)
A simple line of warning in the doc, next to the daemonic-related
methods, should be sufficient to prevent people like me from wondering
weird stuffs for hours ^^

----------

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

From report at bugs.python.org  Mon May  4 21:12:07 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 04 May 2009 19:12:07 +0000
Subject: [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: [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:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 May 2009 19:30:16 +0000
Subject: [issue5920] Confusing float formatting for empty presentation type.
In-Reply-To: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>
Message-ID: <1241465416.76.0.973930264117.issue5920@psf.upfronthosting.co.za>


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

> Wouldn't it make more sense to switch to type 's',
> with a precision of 0, so as to use the same logic that float_str 
uses?

Yes, that makes some sense.  How would you handle 
'{:.10}'.format(10/3.), though?  We could either change 's' to allow a 
precision, or use 's' when there's no precision specified and 'g' (with 
the ADD_DOT_0 flag) otherwise.

> Or, also switch float_str to use 'g' with a precision of
> PyFloat_STR_PRECISION, and get rid of 's' altogether.

This sounds good to me.  It does feel as though there's unnecessary
duplication with the current setup.

----------

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

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: [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:31:08 2009
From: report at bugs.python.org (Anthony Tuininga)
Date: Mon, 04 May 2009 19:31:08 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241465468.08.0.28654633539.issue5311@psf.upfronthosting.co.za>


Anthony Tuininga <anthony.tuininga at gmail.com> added the comment:

I've created another feature request as requested for supplying a
minimum Python version when creating pure Python packages.

http://bugs.python.org/issue5926

----------

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

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: [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 21:51:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 19:51:09 +0000
Subject: [issue5925] Odd formatting differences of keywords in reference
In-Reply-To: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>
Message-ID: <1241466669.67.0.864536398673.issue5925@psf.upfronthosting.co.za>


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

Whare are you seeing this?  The online documentation doesn't use css
class names like the ones you mention as far as I can see.

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

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

From report at bugs.python.org  Mon May  4 21:53:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 19:53:26 +0000
Subject: [issue5925] Odd formatting differences of keywords in reference
In-Reply-To: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>
Message-ID: <1241466806.1.0.208166108597.issue5925@psf.upfronthosting.co.za>


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

Woops, I was looking at the wrong page.  I see it now.

----------

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

From report at bugs.python.org  Mon May  4 21:59:24 2009
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 04 May 2009 19:59:24 +0000
Subject: [issue5926] bdist_msi - add support for minimum Python version for
	pure Python packages
In-Reply-To: <1241465384.5.0.639061880588.issue5926@psf.upfronthosting.co.za>
Message-ID: <1241467164.65.0.90353256744.issue5926@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon May  4 22:00:14 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 20:00:14 +0000
Subject: [issue3739] unicode-internal encoder reports wrong length
In-Reply-To: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>
Message-ID: <1241467214.42.0.00284668180536.issue3739@psf.upfronthosting.co.za>


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

Patch fixing unicode-internal encoder for unicode string input: return 
the length of the input string (number of characters) and not the 
internal size (number of bytes needed to store the text). I wrote a 
small test, I hope that it will be enough (to test the function).

If the input is not an unicode string, return the number of bytes (I 
leaved this case unchanged).

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file13875/issue3739.patch

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

From report at bugs.python.org  Mon May  4 22:10:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 20:10:06 +0000
Subject: [issue5925] Odd formatting differences of keywords in reference
In-Reply-To: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>
Message-ID: <1241467806.14.0.632580483752.issue5925@psf.upfronthosting.co.za>


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

It looks like the py3 table is being colorized incorrectly.  The rst
source code looks the same, so it must be some sort of difference in
configuration.  I think I'll leave it to Georg to sort out :)

----------
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Mon May  4 22:14:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 20:14:10 +0000
Subject: [issue5925] Odd formatting differences of keywords in reference
In-Reply-To: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>
Message-ID: <1241468050.2.0.544955694716.issue5925@psf.upfronthosting.co.za>


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

A thought: there are additional keywords words in the Py3 table. 
Perhaps Sphinx is using a heuristic to detect example blocks that are
python source code, and this one does not qualify in the py2 docs but
does qualify in the p3 docs.  In the py2 docs the table is not colorized
at all.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 22:14:57 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 20:14:57 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1241463240.49.0.377863861559.issue5311@psf.upfronthosting.co.za>
Message-ID: <49FF4CBF.7030101@v.loewis.de>


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

> Thanks! Do I need to do something special to make the merging work
> right? Or do I just apply the patch separately to the trunk and the py3k
> branche?

You commit to the trunk, then you do "svnmerge merge -r<rev>" in the 3k
branch, then "svn commit -F svnmerge-something.txt" (in case of
conflicts, you fix them first, of course).

> Good point about the install script - I think the condition needs to be
> ("&Python%s=3" % ver) instead of "NOT Installed".

I'm not sure - I think the install script must run several times
actually, so there must be several custom actions, each with its own
condition.

> I'll open a new issue for support for a "Change" installation. This is
> one of the nice things that treating Python versions as features allows,
> I just haven't had time to look into it yet.

Well, if there had been separate packages per version, you could install
them independently, anyway.

----------

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

From report at bugs.python.org  Mon May  4 22:20:56 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 May 2009 20:20:56 +0000
Subject: [issue5920] Confusing float formatting for empty presentation type.
In-Reply-To: <1241465416.76.0.973930264117.issue5920@psf.upfronthosting.co.za>
Message-ID: <49FF4EA2.1010502@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

> Yes, that makes some sense.  How would you handle 
> '{:.10}'.format(10/3.), though?  We could either change 's' to allow a 
> precision, or use 's' when there's no precision specified and 'g' (with 
> the ADD_DOT_0 flag) otherwise.

Good point, I hadn't thought of that. I'm not a big fan of switching 
between 's' and 'g' depending on whether a precision is specified.

>> Or, also switch float_str to use 'g' with a precision of
>> PyFloat_STR_PRECISION, and get rid of 's' altogether.
> 
> This sounds good to me.  It does feel as though there's unnecessary
> duplication with the current setup.

A major point of 's' was to not specify the precision, so I'd prefer to 
remove 's' and use 'g' with a specified precision.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May  4 22:26:49 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 04 May 2009 20:26:49 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241468809.95.0.500532946104.issue5923@psf.upfronthosting.co.za>


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

I won't have time to look into this soon.

----------
assignee: loewis -> 

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

From report at bugs.python.org  Mon May  4 22:42:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 20:42:39 +0000
Subject: [issue5925] Odd formatting differences of keywords in reference
In-Reply-To: <1241464326.97.0.957365686198.issue5925@psf.upfronthosting.co.za>
Message-ID: <1241469759.09.0.343797336952.issue5925@psf.upfronthosting.co.za>


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

Pygments' cleverness is detrimental here.  It highlights module, class
and function names specially, therefore the identifiers after "class"
and "import" are differently colored.

I've made the table non-highlighted in 2 and 3, r72288.

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

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

From report at bugs.python.org  Mon May  4 22:45:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 20:45:25 +0000
Subject: [issue5927] Typo in library on xmlrpc
In-Reply-To: <1241465449.18.0.71964516838.issue5927@psf.upfronthosting.co.za>
Message-ID: <1241469925.01.0.465795668158.issue5927@psf.upfronthosting.co.za>


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

Fixed in r72290.

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

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

From report at bugs.python.org  Mon May  4 22:45:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 20:45:34 +0000
Subject: [issue5928] Missing space after period in xmlrpc library documentation
In-Reply-To: <1241465724.43.0.0907945517424.issue5928@psf.upfronthosting.co.za>
Message-ID: <1241469934.52.0.461303368415.issue5928@psf.upfronthosting.co.za>


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

Fixed in r72290.

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

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

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


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

> ... so I'd prefer to remove 's' and use 'g' with a specified precision.

Let's do that then.  I'll update the patch.

----------

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

From report at bugs.python.org  Mon May  4 22:49:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 20:49:28 +0000
Subject: [issue5916] Wrong function referenced in documentation of
	socket.inet_aton
In-Reply-To: <1241388198.89.0.66136453957.issue5916@psf.upfronthosting.co.za>
Message-ID: <1241470168.41.0.970549453762.issue5916@psf.upfronthosting.co.za>


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

Thanks, applied in r72292.

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

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

From report at bugs.python.org  Mon May  4 22:49:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 20:49:37 +0000
Subject: [issue5917] Reference platform-independent alternative in
	socket.inet_ntop documentation
In-Reply-To: <1241388586.38.0.920530904266.issue5917@psf.upfronthosting.co.za>
Message-ID: <1241470177.45.0.308228833006.issue5917@psf.upfronthosting.co.za>


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

Thanks, applied in r72292.

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

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

From report at bugs.python.org  Mon May  4 22:53:44 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 May 2009 20:53:44 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241470424.79.0.0450339921593.issue5915@psf.upfronthosting.co.za>


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

Aside from Antoine's comments, I think it looks good now.

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

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

From report at bugs.python.org  Mon May  4 22:54:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 20:54:50 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241470490.13.0.982221833451.issue5890@psf.upfronthosting.co.za>


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

Updated patch that updates property_copy so that the __doc__ string is
also copied appropriately when getter, setter, or deller are used.  A
bunch more tests, as well. I refactored property_copy to make it reuse
the logic in property_init directly.

Unfortunately I've got a refleak somewhere in there (regrtest -R :: says
[8, 8, 8, 8].  Hopefully fresh and more experienced eyes can help me out.

----------
Added file: http://bugs.python.org/file13876/issue5890.patch

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

From report at bugs.python.org  Mon May  4 22:55:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 20:55:24 +0000
Subject: [issue2660] Py3k fails to parse a file with an iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1241470524.75.0.325277771334.issue2660@psf.upfronthosting.co.za>


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

Patch using tokenize.detect_encoding() to read the encoding of Python 
scripts instead of using default io.open() encoding (utf-8).

We might write unit test.

See also related issue: #5093

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file13877/2to3_encoding.patch

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

From report at bugs.python.org  Mon May  4 23:09:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 21:09:19 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241471359.18.0.592942630338.issue5890@psf.upfronthosting.co.za>


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

Updated patch with refleak fixed.  Thanks Georg.

----------
Added file: http://bugs.python.org/file13878/issue5890.patch

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

From report at bugs.python.org  Mon May  4 23:09:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 21:09:26 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241471366.29.0.184347227182.issue5890@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13832/issue5890.patch

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

From report at bugs.python.org  Mon May  4 23:09:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2009 21:09:31 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241471371.05.0.991037598513.issue5890@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file13876/issue5890.patch

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

From report at bugs.python.org  Mon May  4 23:12:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 21:12:18 +0000
Subject: [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1241471538.59.0.708445048343.issue5692@psf.upfronthosting.co.za>


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

Benjamin oked the patch on IRC.

----------
assignee:  -> pitrou
resolution:  -> accepted

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

From report at bugs.python.org  Mon May  4 23:13:33 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Mon, 04 May 2009 21:13:33 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241471613.58.0.12985869667.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

Ok, I've tried to solve this problem, but I think that the keyword
'easy' is not suitable for this kind of task, because it is necessary to
modify the expat module that is very complex.

----------

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

From report at bugs.python.org  Mon May  4 23:18:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 21:18:11 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241471891.3.0.992639880958.issue5923@psf.upfronthosting.co.za>


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

Had a quick look over the patch, and couldn't find ab obvious problem
(except one -- you maybe want to comment out "print(_ver)" again).

Needs a docs patch, though.

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

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

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: [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:25:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 May 2009 21:25:13 +0000
Subject: [issue5692] test_zipfile fails under Windows
In-Reply-To: <1238865433.18.0.587625961619.issue5692@psf.upfronthosting.co.za>
Message-ID: <1241472313.42.0.765535151234.issue5692@psf.upfronthosting.co.za>


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

Fixed in r72295, r72296, r72297.

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

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

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: [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  Mon May  4 23:35:16 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 04 May 2009 21:35:16 +0000
Subject: [issue5930] Transient error in multiprocessing
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1241472916.35.0.143963166527.issue5930@psf.upfronthosting.co.za>


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

there's not much I can do without the ability to reproduce it :(

----------

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

From report at bugs.python.org  Tue May  5 00:08:35 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 04 May 2009 22:08:35 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241474915.44.0.378628700421.issue5923@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I just wanted to submit the reply below. In the meantime Benjamin's
remark arrived. So perhaps the issue can be resolved successfully.

May I submit here one of the two example scripts I'd like to add to the
demos: tdemo_round_dance.py . Have a look at it and run it. 
Just for fun - in this strained situation - I hope you enjoy it.

I'll prepare the patch for the docs and I'll submit it as soon as
possible, not later than tomorrow.

Of course the print(_ver) statement should be commented out.

Regards,
Gregor

-----------------------------------------------------------

So perhaps there is someone else who could do it.

I'd like to state decisively:

Version 1.1 contains significant amendments.
I tested it thoroughly 
It would be a big advantage if others could test it also
during the 4 weeks of beta testing.

So I'd like to ask: Would it be practicable to put it
into 3.1b with the caveat to revert this adoption if it
turns out to have unrecoverable flaws? 

I'd like to remind you that Martin even did significant 
changes to version 1.0 only a few days before the final 
release of Python2.6. 

I know (and regret) that I submitted these changes rather late, 
but it was four days ago that I asked Martin and also Raymond for
advice on how to proceed with the submission but regrettably with 
no response. Unfortunately I'm a full time teacher and have to
do a lot of final exams these days. So I have only limited 
resources to work on turtle development. Nevertheless 
I'm anxious to only deliver valuable contributions.

I hope there is a way to accept these for now.
Regards
Gregor

----------
Added file: http://bugs.python.org/file13879/tdemo_round_dance.py

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

From report at bugs.python.org  Tue May  5 00:11:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 May 2009 22:11:15 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1241475075.86.0.0613970045207.issue5922@psf.upfronthosting.co.za>


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


----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Tue May  5 00:14:24 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 04 May 2009 22:14:24 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241475264.28.0.293033016217.issue5923@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Here the patch to comment out the print(_ver) statement

----------
Added file: http://bugs.python.org/file13880/print_ver_patch.diff

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

From report at bugs.python.org  Tue May  5 00:15:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 May 2009 22:15:22 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241475322.64.0.106107933575.issue5923@psf.upfronthosting.co.za>


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

Gregor, I'll have a more thorough look and commit the patch before
3.1b1, if you promise to submit a patch to the documentation later --
that one can go in until a few days before final anyway.

----------

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

From report at bugs.python.org  Tue May  5 00:22:42 2009
From: report at bugs.python.org (Adam Goode)
Date: Mon, 04 May 2009 22:22:42 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't be
	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1241475762.81.0.481655350341.issue5504@psf.upfronthosting.co.za>


Adam Goode <adam at spicenitz.org> added the comment:

Currently there is an issue where allow_execstack implies allow_execmem.
Even though allow_execmem is default to off, allow_execstack is default
to on. If this issue is fixed, or if the administrator sets
allow_execstack to off, ctypes will fail.

Try this as root, then repeat your test:
semanage boolean -m --off allow_execstack

----------

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

From report at bugs.python.org  Tue May  5 00:25:39 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 May 2009 22:25:39 +0000
Subject: [issue5881] Remove extraneous backwards-compatibility attributes from
	some modules
In-Reply-To: <1241023805.22.0.886564039533.issue5881@psf.upfronthosting.co.za>
Message-ID: <1241475939.82.0.984198657784.issue5881@psf.upfronthosting.co.za>


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

Applied in r72300.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Tue May  5 00:33:36 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2009 22:33:36 +0000
Subject: [issue5929] warnings in unicodeobject.c
In-Reply-To: <1241471984.38.0.629165651033.issue5929@psf.upfronthosting.co.za>
Message-ID: <1241476416.38.0.723533021087.issue5929@psf.upfronthosting.co.za>


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

Use "const char*" fixes this issue.

Note: the warning was introduced by r72260 (issue #5108).

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file13881/unicode_warning.patch

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

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: [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 01:15:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 May 2009 23:15:15 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1241478915.55.0.78285556488.issue5931@psf.upfronthosting.co.za>


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


----------
assignee:  -> pje
nosy: +pje

_______________________________________
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: [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: [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:26:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2009 00:26:23 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241483183.68.0.65663494726.issue5933@psf.upfronthosting.co.za>


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

Another patch to fix similar warnings in resource modules.

----------
Added file: http://bugs.python.org/file13884/sign_warning_resource.patch

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

From report at bugs.python.org  Tue May  5 02:28:06 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 05 May 2009 00:28:06 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241483286.82.0.246127911214.issue5923@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Here is a patch for the documentation. It may contain some typos and/or
inaccuracies. I promise to check it and submit a patch if necessary
before final.

It contains also the announcement of two new demo scripts, the one
beeing round_dance submitted already, the other one being a nim game.
I'll submit it subsequently

Regards,
Gregor

----------
Added file: http://bugs.python.org/file13885/turtle31.rst.diff

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

From report at bugs.python.org  Tue May  5 02:31:01 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 05 May 2009 00:31:01 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241483461.07.0.216535604592.issue5923@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

The second demo script just announced

----------
Added file: http://bugs.python.org/file13886/tdemo_nim.py

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

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: [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 02:50:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 00:50:09 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241484609.84.0.369968967488.issue5799@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

> I've generated a new patch, attached.  I don't know why you had trouble
> applying.

Yeah, I'm not sure what that was about. Part of the patch applied, but
not the rest. In any event, the current one applied cleanly.

I'm not sure this part of the patch is correct (in relpath):
     for i in range(min(len(start_list), len(path_list))):
-        if start_list[i].lower() != path_list[i].lower():
+        if start_list[i] != path_list[i]:
             break
-    else:
         i += 1

I think removing the "else:" is likely an error. It probably also means
that this code isn't tested.

Other than that, this looks reasonable enough to me. I'm hoping someone
else can give it a thorough review, too. I haven't had time to look
through all of the cases in join() to verify that they're correct and
complete.

----------

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

From report at bugs.python.org  Tue May  5 02:52:04 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 05 May 2009 00:52:04 +0000
Subject: [issue5643] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1238586550.45.0.844379263332.issue5643@psf.upfronthosting.co.za>
Message-ID: <1241484724.46.0.542220036897.issue5643@psf.upfronthosting.co.za>


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

Probably this patch works on recent VisualC++. But unfortunately, this
code crashes on VisualC++6 debug build. :-(

This happens when 2nd arg of setlocale contains "." and the length of
substring after "." is longer than 8. It seems to be msvcrtd bug.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file13888/py3k_locale_test_on_windows.patch

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

From report at bugs.python.org  Tue May  5 03:03:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 01:03:20 +0000
Subject: [issue5890] Subclassing property doesn't preserve the auto __doc__
	behavior
In-Reply-To: <1241129592.84.0.608165277997.issue5890@psf.upfronthosting.co.za>
Message-ID: <1241485400.65.0.222086900804.issue5890@psf.upfronthosting.co.za>


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

Reviewed by Georg and approved on #python-dev.  Committed in r72299,
r72301, r72302, and r72304.

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

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

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: [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:15:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 02:15:41 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241489741.13.0.0732452391424.issue5923@psf.upfronthosting.co.za>


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

Gregor, I applied my doctest fixups to turtle.rst in the py3k branch in
r72307.  I've attached an updated version of your docpatch that applies
against this new revision.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file13889/issue5923.doc.patch

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

From report at bugs.python.org  Tue May  5 04:23:32 2009
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 05 May 2009 02:23:32 +0000
Subject: [issue5311] bdist_msi generates version number for pure Python
	packages
In-Reply-To: <1235016969.03.0.818386696301.issue5311@psf.upfronthosting.co.za>
Message-ID: <1241490212.45.0.0852179688809.issue5311@psf.upfronthosting.co.za>


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

> You commit to the trunk, then you do "svnmerge merge -r<rev>" in the 
> 3k branch, then "svn commit -F svnmerge-something.txt" (in case of
> conflicts, you fix them first, of course).

Done in r72306 for trunk and r72309 for 3k. Thanks.

> I'm not sure - I think the install script must run several times
> actually, so there must be several custom actions, each with its own
> condition.

Yep. That's what the patch does - adds a CustomAction and an entry in
InstallExecuteSequence for each version.

> Well, if there had been separate packages per version, you could 
> install them independently, anyway.

For what it's worth, you still have this option if anyone wants to
distribute multiple MSIs. Simply pass --target-version to bdist_msi, and
you'll get an MSI for only the selected version of Python that you can
install independently of other MSIs generated with --target-version.

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

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

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: [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 04:34:57 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 02:34:57 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241490897.77.0.0648972015658.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Sweet jumping rhubarb!  I didn't know about this "for ...: else:"
construct in Python.  When I was editing it I thought it was my editor
stumbling over a tab, and the "else" went with the "if" *inside* the
"for".  You're absolutely right that the current code is utter nonsense;
the "i += 1" gets overwritten immediately by the for loop.

On the other hand: the original code is wrong too.
  for i in whatever:
    something()
  else:
    i += 1
If the for loop is not executed, "i" is undefined, so adding 1 to it is
a runtime error.

Then again!  In the existing code the loop always executes at least
once, because it's iterating over the split of the absolute path, rather
than starting at the root of the current drive.  So the "else:" is
unnecessary.

What the "i += 1" is *probably* trying to do is fix this bug:
  >>> ntpath.relpath("/foo/bar/bat", "/")
  "../foo/bar/bat"
If the lists the for loop was examining skipped the drive letter (or UNC
path), the for loop wouldn't exit.  Maybe they used to have "i = 0"
above the loop or something, in which case this would probably have worked.

Sadly this bug is in both my version and the current version.

I will fix this bug, add a test case, and file a new patch, hopefully
tonight.

----------

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

From report at bugs.python.org  Tue May  5 05:19:26 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 03:19:26 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241493566.59.0.0708830145257.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

As promised, a fresh patch.  Note that the current formulation of that
troublesome loop in relpath() is *very* much on purpose.  The removal of
the "else" is no longer a bug :)

----------
Added file: http://bugs.python.org/file13890/lch.ntpath.r72309.diff

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

From report at bugs.python.org  Tue May  5 05:24:14 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 03:24:14 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241493854.76.0.45715216184.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Sorry for the quick double-patch, but I realized that there was no test
for the obverse case, where "path" is / and "curdir" is non-empty.  So I
threw in some more tests.

----------
Added file: http://bugs.python.org/file13891/lch.ntpath.r72309.diff.2

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 06:02:27 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 04:02:27 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <0015174becfcb26b6704692258c2@google.com>


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

Fixed in r72310

http://codereview.appspot.com/52095/diff/30/1013
File Lib/test/test_codecs.py (right):

http://codereview.appspot.com/52095/diff/30/1013#newcode1545
Line 1545: b"foo\xa5bar")
On 2009/05/04 12:25:43, Antoine Pitrou wrote:
> You decode with iso-8859-3 but encode with iso-8859-4. Is it intended?

No, fixed.

http://codereview.appspot.com/52095/diff/30/1014
File Lib/test/test_os.py (right):

http://codereview.appspot.com/52095/diff/30/1014#newcode704
Line 704: filenames = [b'foo\xf6bar', b'foo\xf6bar']
On 2009/05/04 12:25:43, Antoine Pitrou wrote:
> Is my sight bad, or is this twice the same filename?

Oops, fixed.

http://codereview.appspot.com/52095/diff/30/1016
File Modules/python.c (right):

http://codereview.appspot.com/52095/diff/30/1016#newcode47
Line 47: /* Try conversion with mbsrtwocs (C99), and escape
non-decodable bytes. */
On 2009/05/04 12:25:43, Antoine Pitrou wrote:
> Typo: s/mbsrtwocs/mbrtowc/

Done.

http://codereview.appspot.com/52095

----------

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

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: [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 =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 06:44:06 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 04:44:06 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1241498646.11.0.216130365569.issue5915@psf.upfronthosting.co.za>


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

Committed as r72313

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

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

From report at bugs.python.org  Tue May  5 07:06:43 2009
From: report at bugs.python.org (Tim Golden)
Date: Tue, 05 May 2009 05:06:43 +0000
Subject: [issue5935] Better documentation of use of BROWSER environment
	variable
In-Reply-To: <1241489630.51.0.91257880678.issue5935@psf.upfronthosting.co.za>
Message-ID: <49FFC93C.3010206@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Edmund Eyles wrote:
> 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.

Arguably, that is (implictly) standard behaviour on Windows: if
you invoke a program with its name alone, it generally has to
be on the PATH. However... Firefox (and IE) use the AppPaths
registry entries to ensure that someone using *shell* functionality
such as Start > Run or ShellExecute need only enter "firefox".
The webbrowser module doesn't perform this particular indirection,
hence the OP's confusion.

----------
nosy: +tim.golden

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

From report at bugs.python.org  Tue May  5 07:39:32 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 05:39:32 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241501972.35.0.381094208417.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I stared at it some more.  Now I understand what "for ... : else:" was
for in the original.  The "else: i += 1" ensures that if the "for" loop
runs to completion "i" is set to the length of the shorter of the two
lists.  Anyway, my reimplemented loop accomplishes this in a slightly
easier-to-read style.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 09:00:15 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 07:00:15 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241506815.62.0.231452897523.issue5753@psf.upfronthosting.co.za>


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

I disagree that this issue is release critical. I'm still skeptical that
this is a security bug; if it is, any solution created needs to be
applied to all active branches - including the ones that would be
blocked by this issue right now. IOW, it's still possible to fix it
after the release.

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

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

From report at bugs.python.org  Tue May  5 09:14:29 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 07:14:29 +0000
Subject: [issue5630] Create alternative CObject API that is safe and clean
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1241507669.61.0.351883726512.issue5630@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

dalcinl: Thanks, I've fixed the doc wrt writing "int" where I meant
"void *".

As for using "disambiguate" in many places: there are a couple of
sentences that are repeated in the documentation for several functions.
 Those repeated sentences all use "ambiguous" and "disambiguate". 
Having them read almost exactly the same is a subtle cue to the reader,
suggesting they will behave similarly, which is correct.  Is that a problem?

----------

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

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: [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: [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 09:49:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 07:49:40 +0000
Subject: [issue5932] _json: _convertPyInt_AsSsize_t() never raise any error
In-Reply-To: <1241482913.08.0.841842039373.issue5932@psf.upfronthosting.co.za>
Message-ID: <1241509780.2.0.10367444814.issue5932@psf.upfronthosting.co.za>


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

Applied in r72314.

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

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

From report at bugs.python.org  Tue May  5 09:51:53 2009
From: report at bugs.python.org (sol)
Date: Tue, 05 May 2009 07:51:53 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1241509913.83.0.532198937824.issue3585@psf.upfronthosting.co.za>


sol <simon.hengel at wiktory.org> added the comment:

>> - Shouldn't this file be installed only if the pkg-config utility is
>> present, or if the directory $(LIBDIR)/pkgconfig already exists?
>
> Technically I suppose so
>

That would mean that, if you first install Python and afterwards
pkg-config, pkg-config would not work for Python, right? I'm not sure if
that would be desirable.

----------
nosy: +sol

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

From report at bugs.python.org  Tue May  5 09:55:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 07:55:39 +0000
Subject: [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: <1241510139.8.0.370247647057.issue5938@psf.upfronthosting.co.za>


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

Thanks, fixed in r72317.

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

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

From report at bugs.python.org  Tue May  5 10:01:07 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 08:01:07 +0000
Subject: [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: <1241510467.54.0.895002224547.issue5938@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Whoops, I thought PEP 3123 applied to 2.7 as well.  PEP *3*123.  Duh, me
slow today.

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

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

From report at bugs.python.org  Tue May  5 10:06:49 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 08:06:49 +0000
Subject: [issue5630] Create alternative CObject API that is safe and clean
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1241510809.79.0.921057312952.issue5630@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

A nice fresh patch, against r72309.  Incorporates changes based on
Benjamin's latest batch of Rietveld comments.  They're thinning out, so
we must be near the end--and with a day to spare.  Also strips out
almost-all documentation from "pycapsule.h".

Note: this still has CObject flagged as deprecated, both in doc and with
a runtime warning.  Dare I hope these will survive into the accepted patch?

----------
Added file: http://bugs.python.org/file13892/lch.capsule.r72309.diff

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

From report at bugs.python.org  Tue May  5 10:15:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 08:15:41 +0000
Subject: [issue5923] turtle.py update: 1.0 --> 1.1
In-Reply-To: <1241448998.35.0.421057037776.issue5923@psf.upfronthosting.co.za>
Message-ID: <1241511341.82.0.529850392825.issue5923@psf.upfronthosting.co.za>


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

OK, I committed turtle30_to_31.diff, and additionally commented the
print(_ver) out and updated the version in the comment at the file's
top, and committed issues5923.doc.patch in r72318.

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

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

From report at bugs.python.org  Tue May  5 10:17:57 2009
From: report at bugs.python.org (Stefan Ring)
Date: Tue, 05 May 2009 08:17:57 +0000
Subject: [issue5912] import deadlocks when using fork
In-Reply-To: <1241351428.83.0.293714766412.issue5912@psf.upfronthosting.co.za>
Message-ID: <1241511477.87.0.462756041019.issue5912@psf.upfronthosting.co.za>


Changes by Stefan Ring <stefanrin at gmail.com>:


----------
nosy: +Ringding

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

From report at bugs.python.org  Tue May  5 10:21:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 08:21:17 +0000
Subject: [issue1068477] linecache.py::updatecache strips directory info from
	files
Message-ID: <1241511677.5.0.69435170839.issue1068477@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
dependencies:  -linecache module returns wrong results
resolution:  -> duplicate
status: open -> closed
superseder:  -> linecache module returns wrong results

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

From report at bugs.python.org  Tue May  5 10:22:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 08:22:18 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1241511738.62.0.367776843717.issue1754483@psf.upfronthosting.co.za>


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

Setting #1309567 as superseder.

----------
dependencies:  -linecache module returns wrong results
resolution:  -> duplicate
status: open -> closed
superseder:  -> linecache module returns wrong results

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

From report at bugs.python.org  Tue May  5 10:25:21 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 08:25:21 +0000
Subject: [issue1068477] linecache.py::updatecache strips directory info from
	files
Message-ID: <1241511921.95.0.934767542744.issue1068477@psf.upfronthosting.co.za>


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

Setting #1309567 as superseder.

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

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

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: [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 10:30:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 08:30:47 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1241512247.07.0.267122449149.issue1309567@psf.upfronthosting.co.za>


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

Applied patch and added test suite in r72319.

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

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

From report at bugs.python.org  Tue May  5 10:31:27 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 May 2009 08:31:27 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241456696.27.0.0946656062216.issue5902@psf.upfronthosting.co.za>
Message-ID: <49FFF972.9060208@egenix.com>


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

On 2009-05-04 19:04, Georg Brandl wrote:
> Georg Brandl <georg at python.org> added the comment:
> 
> So, do you also think "utf" and "latin" should stay?

For Python 3.x, I think those can be removed. For 2.x it's better to
keep them.

Note that UTF-8 was the first official Unicode transfer encoding,
that's why it's sometimes referred to as "UTF".

The situation is similar for Latin-1. It was the first of a series of
encodings defined by ECMA which was later published by ISO under the name
ISO-8859 - long after the name "Latin-1" became popular which is why
it's the default name in Python.

----------

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

From report at bugs.python.org  Tue May  5 10:48:54 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 05 May 2009 08:48:54 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't
	be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1241475762.81.0.481655350341.issue5504@psf.upfronthosting.co.za>
Message-ID: <49FFFD6A.9080803@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> Try this as root, then repeat your test:
> semanage boolean -m --off allow_execstack

Ok, I can reproduce the problem now.  Thanks!

----------
title: ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC -> ctypes should work with systems where mmap can't be	PROT_WRITE and PROT_EXEC

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

From report at bugs.python.org  Tue May  5 10:54:54 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 08:54:54 +0000
Subject: [issue5142] pdb feature request: Ability to skip standard lib modules
	and other selected packages/modules
In-Reply-To: <1233669109.05.0.519121201366.issue5142@psf.upfronthosting.co.za>
Message-ID: <1241513694.75.0.920939089825.issue5142@psf.upfronthosting.co.za>


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

Applied the patch, added documentation and committed it as r72322. Thanks!

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

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

From report at bugs.python.org  Tue May  5 10:56:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 08:56:48 +0000
Subject: [issue5920] Confusing float formatting for empty presentation type.
In-Reply-To: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>
Message-ID: <1241513808.6.0.932090238855.issue5920@psf.upfronthosting.co.za>


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

Updated patch, that removes the 's' type code.

----------
Added file: http://bugs.python.org/file13893/issue5920_v2.patch

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

From report at bugs.python.org  Tue May  5 11:05:58 2009
From: report at bugs.python.org (Clinton Roy)
Date: Tue, 05 May 2009 09:05:58 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1241514358.94.0.308720465949.issue3585@psf.upfronthosting.co.za>


Clinton Roy <clinton.roy at gmail.com> added the comment:

Hi Sol,

It's just a data file I suppose, Python should not need a dependency on
pkg-config, and neither should there be a python-pkgconfig package that
just contains the python.pc file.

I think the approach to just always install the python.pc file is the
right one.

----------

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

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: [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 11:09:34 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 09:09:34 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241514574.21.0.698762571076.issue5799@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This looks okay to me. (The itertools import isn't needed, but easy
enough to fix on checkin.)

I'd still like someone else to look it over, but if no one does before
the beta, I'll check it in.

----------
keywords: +needs review
stage:  -> patch review

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

From report at bugs.python.org  Tue May  5 11:14:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 09:14:39 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox
Message-ID: <1241514879.88.0.708197600605.issue1356969@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: loewis -> gpolo
nosy: +gpolo

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May  5 11:14:48 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: Tue, 05 May 2009 09:14:48 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241514888.43.0.72674543388.issue5941@psf.upfronthosting.co.za>


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

Hi David, do you have an example that breaks, I can reuse to write the
test ?

----------

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

From report at bugs.python.org  Tue May  5 11:17:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 09:17:18 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241515038.54.0.266338569699.issue5933@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson

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

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


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

Hi Tarek,

Yes, I have a simple example, which show both 5940 and 5941 bugs:

"""
from distutils.core import setup

# How to install libfoo.a/foo.lib in say pkg_dir/lib ?
setup(name='yo', libraries=[('foo', {'sources': ['foo.c']})])
"""

foo.c can be an empty file.

----------

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May  5 11:19:31 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: Tue, 05 May 2009 09:19:31 +0000
Subject: [issue5940] Wrong type check in check_library_list
In-Reply-To: <1241512069.38.0.233347773971.issue5940@psf.upfronthosting.co.za>
Message-ID: <1241515171.17.0.222972784202.issue5940@psf.upfronthosting.co.za>


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

Good catch !

Obviously this was introduced when the Python 2 version was
refactored for Python 3

(in python 2 its "if type(lib[0]) is not StringType")

I shall fix this today or tonite (I need to add test coverage
for this command)

----------
priority:  -> critical

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

From report at bugs.python.org  Tue May  5 11:19:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 09:19:56 +0000
Subject: [issue5929] warnings in unicodeobject.c
In-Reply-To: <1241471984.38.0.629165651033.issue5929@psf.upfronthosting.co.za>
Message-ID: <1241515196.1.0.380525258498.issue5929@psf.upfronthosting.co.za>


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

Fixed in r72326.

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

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

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


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

Both should be set as serious, in the sense that build_clib is totally
broken ATM, with no simple workaround. OTOH, maybe numpy is the only
user of build_clib, in which case it is not so serious (I use my own
fixed, copied versions of the original code for the time being in numpy
distutils extensions).

----------

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

From report at bugs.python.org  Tue May  5 11:23:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 May 2009 09:23:10 +0000
Subject: [issue5919] pygettext documentation
In-Reply-To: <1241433644.84.0.826076454986.issue5919@psf.upfronthosting.co.za>
Message-ID: <1241515390.45.0.148940593804.issue5919@psf.upfronthosting.co.za>


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

This depends on how the distribution installs pygettext.  For example,
on Gentoo it isn't installed as a command at all.

Since the original name in the Python source archive is "pygettext.py",
I'll not change this.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Tue May  5 11:34:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 May 2009 09:34:11 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241516051.49.0.00702526516001.issue5753@psf.upfronthosting.co.za>


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

Ok, downgrading to critical.
I'm awaiting the reporter's answer anyway.

----------

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

From report at bugs.python.org  Tue May  5 11:34:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 May 2009 09:34:20 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241516060.05.0.214075751769.issue5753@psf.upfronthosting.co.za>


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


----------
priority: release blocker -> critical

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

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


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

About sign_warning_resource.patch: I don't know if RLIM_INFINITY 
constant is standard (always defined if getrlimit() is present).

----------

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

From report at bugs.python.org  Tue May  5 14:31:39 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 12:31:39 +0000
Subject: [issue5920] Confusing float formatting for empty presentation type.
In-Reply-To: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>
Message-ID: <1241526699.66.0.530029545299.issue5920@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I've reviewed this and it looks good. I'll check it in to py3k shortly.
Then I'll backport it to 2.7 and fix the user documentation.

----------
resolution:  -> accepted
stage: patch review -> 

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

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: [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: [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 17:52:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 15:52:23 +0000
Subject: [issue5943] Bus error in test_posix on Mac OS
In-Reply-To: <1241532751.75.0.224602720021.issue5943@psf.upfronthosting.co.za>
Message-ID: <1241538743.67.0.795789259697.issue5943@psf.upfronthosting.co.za>


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

FreeBSD 6.3 also gives a segfault in test_posix.  Gentoo runs fine.

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 18:15:38 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 16:15:38 +0000
Subject: [issue5847] IDLE/Win Installer: drop -n switch for 2.7/3.1;
	install 3.1 as idle3
In-Reply-To: <1240715305.76.0.471826786959.issue5847@psf.upfronthosting.co.za>
Message-ID: <1241540138.71.0.452726616969.issue5847@psf.upfronthosting.co.za>


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

The -n switch is now removed in r72335, r72336.

----------

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

From report at bugs.python.org  Tue May  5 18:17:37 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 05 May 2009 16:17:37 +0000
Subject: [issue5643] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1238586550.45.0.844379263332.issue5643@psf.upfronthosting.co.za>
Message-ID: <1241540257.8.0.429786362084.issue5643@psf.upfronthosting.co.za>


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

Crashes at Lib/test/test__locale.py(107) test_float_parsing.

>>> from _locale import setlocale, LC_NUMERIC
>>> setlocale(LC_NUMERIC, 'es_ES.ISO8859-1')
(crash)

Yes, I agree that workaround should be placed in test rather than
_locale module. I'll create such patch as short as possible.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 18:23:53 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 16:23:53 +0000
Subject: [issue5847] IDLE/Win Installer: drop -n switch for 2.7/3.1;
	install 3.1 as idle3
In-Reply-To: <1240715305.76.0.471826786959.issue5847@psf.upfronthosting.co.za>
Message-ID: <1241540633.57.0.943058920979.issue5847@psf.upfronthosting.co.za>


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

I'm not sure what the necessary action is on the idle script. It's not
used on Windows; it isn't even installed. So unassigning myself.

----------
assignee: loewis -> 

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

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


Eric Smith <eric at trueblade.com> added the comment:

Fedora Core 6 works okay.

----------

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

From report at bugs.python.org  Tue May  5 18:36:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 16:36:37 +0000
Subject: [issue5943] Bus error in test_posix on Mac OS
In-Reply-To: <1241532751.75.0.224602720021.issue5943@psf.upfronthosting.co.za>
Message-ID: <1241541397.19.0.551611971009.issue5943@psf.upfronthosting.co.za>


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

Does this patch fix the problem?

----------
keywords: +patch
nosy: +marketdickinson
Added file: http://bugs.python.org/file13894/issue5943.patch

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

From report at bugs.python.org  Tue May  5 18:47:50 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 05 May 2009 16:47:50 +0000
Subject: [issue5643] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1238586550.45.0.844379263332.issue5643@psf.upfronthosting.co.za>
Message-ID: <1241542070.69.0.958197236097.issue5643@psf.upfronthosting.co.za>


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

Revised patch against HEAD. (With VC6 workaround)

----------
Added file: http://bugs.python.org/file13895/py3k_locale_test_on_windows.patch

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

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


Eric Smith <eric at trueblade.com> added the comment:

Yes, that patch fixes the problem for me on Mac OS.

----------

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

From report at bugs.python.org  Tue May  5 18:52:45 2009
From: report at bugs.python.org (Ben Gamari)
Date: Tue, 05 May 2009 16:52:45 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1241542365.08.0.639124562217.issue1368247@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

What is the status of this?

----------
nosy: +bgamari

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

From report at bugs.python.org  Tue May  5 18:55:29 2009
From: report at bugs.python.org (Ben Gamari)
Date: Tue, 05 May 2009 16:55:29 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1241542529.65.0.967019271914.issue4487@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

Has this patch been merged yet?

----------
nosy: +bgamari

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

From report at bugs.python.org  Tue May  5 18:57:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 16:57:48 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241542668.91.0.265780545753.issue5933@psf.upfronthosting.co.za>


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

Thanks for the patches.

The first patch looks fine;  I'll apply it shortly.

For the second, I don't understand why you want to
compare the return result with RLIM_INFINITY:  PyInt_AsLong
returns -1 to signal failure;  is there some guarantee that
RLIM_INFINITY == -1 if it's defined?

----------

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

From report at bugs.python.org  Tue May  5 19:00:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 17:00:54 +0000
Subject: [issue5943] Bus error in test_posix on Mac OS
In-Reply-To: <1241532751.75.0.224602720021.issue5943@psf.upfronthosting.co.za>
Message-ID: <1241542854.45.0.0352113642602.issue5943@psf.upfronthosting.co.za>


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

Fixes it on FreeBSD 6.3 as well.

----------

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

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


Mitchell Model <mlm at acm.org> added the comment:

Further confusion:
    dbm.dumb._Database objects DO support items(), DO NOT support
iteritems(), and DO support iterkeys()

My previous comments referred to the general dbm documentation and the
specifics of dbm.gnu. I haven't checked any of this against the Unix
ndbm implementation.

----------

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

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


Eric Smith <eric at trueblade.com> added the comment:

My Fedora Core 6 box still works with the patch.

----------

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

From report at bugs.python.org  Tue May  5 19:13:23 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 17:13:23 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241543603.58.0.0104298441279.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Whoops, yeah, that was me forgetting that in py3k itertools.izip became
just "zip".  I'll remove it in my branch in case I generate another patch.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 19:19:22 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 17:19:22 +0000
Subject: [issue5943] Bus error in test_posix on Mac OS
In-Reply-To: <1241532751.75.0.224602720021.issue5943@psf.upfronthosting.co.za>
Message-ID: <1241543962.62.0.352773248191.issue5943@psf.upfronthosting.co.za>


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

This is now fixed in r72340 (I came up with the same patch
independently, and just hadn't got around to commit it).

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

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

From report at bugs.python.org  Tue May  5 19:23:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 17:23:51 +0000
Subject: [issue5884] pydoc to return error status code
In-Reply-To: <1241053592.21.0.872598622661.issue5884@psf.upfronthosting.co.za>
Message-ID: <1241544231.17.0.770682798248.issue5884@psf.upfronthosting.co.za>


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

This seems like a resonable thing for pydoc to do.  However, I took a
quick look, and pydoc has no notion of error status. Adding one would
require a non-trival refactoring of the code (at least to do it
right...a hackish version might not be too difficult).  

So, I doubt this is going to happen unless you can contribute a patch.

On the other hand, your test suite should be catching any errors pydoc
would catch, so I can't say I really understand your stated reason for
the request.  Unless you are building documentation for packages you
don't maintain?

----------
nosy: +r.david.murray
priority:  -> low
stage:  -> needs patch
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Tue May  5 19:35:57 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 17:35:57 +0000
Subject: [issue5861] test_urllib fails on windows
In-Reply-To: <1240883003.46.0.843478025116.issue5861@psf.upfronthosting.co.za>
Message-ID: <1241544957.72.0.753398985585.issue5861@psf.upfronthosting.co.za>


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

Fixed this in the revision: 72343. Agree to the comment on replacing '|'
to ':' in pathname2url as windows recognizes it. test_urllib passes.

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

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

From report at bugs.python.org  Tue May  5 19:49:17 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 17:49:17 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241545757.01.0.324214913882.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Just 'cause I like you, here's an updated patch.  The only change is the
removal of "import itertools" and the update of the base version.

----------
Added file: http://bugs.python.org/file13896/lch.ntpath.r72345.diff

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

From report at bugs.python.org  Tue May  5 19:55:22 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 17:55:22 +0000
Subject: [issue918368] urllib doesn't correct server returned urls
Message-ID: <1241546122.25.0.472377103496.issue918368@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


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

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

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: [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 20:09:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 18:09:03 +0000
Subject: [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: <1241546943.39.0.445106495608.issue5944@psf.upfronthosting.co.za>


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

One other piece of information that may be relevant:

Macintosh-4:py3k dickinsm$ echo $LANG
en_US.UTF-8

If I unset the LANG environment variable then I get a different failure  
(see output below).

I'll investigate this further and see if I can figure out what's going 
wrong.



test_setreuid (__main__.PosixUidGidTests) ... ok
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 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 853, 
in _run_suite
    result = runner.run(suite)
  File "/Users/dickinsm/svn/python/py3k/Lib/unittest.py", line 1455, in 
run
    result.printErrors()
  File "/Users/dickinsm/svn/python/py3k/Lib/unittest.py", line 1424, in 
printErrors
    self.printErrorList('FAIL', self.failures)
  File "/Users/dickinsm/svn/python/py3k/Lib/unittest.py", line 1431, in 
printErrorList
    self.stream.writeln("%s" % err)
  File "/Users/dickinsm/svn/python/py3k/Lib/unittest.py", line 1340, in 
writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode character '\u0308' in 
position 194: ordinal not in range(128)

----------

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

From report at bugs.python.org  Tue May  5 20:10:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 18:10:17 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241547017.34.0.257073917656.issue5933@psf.upfronthosting.co.za>


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

Applied the first patch in r72344, r72345, r72346, r72347.

----------

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

From report at bugs.python.org  Tue May  5 20:27:47 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 18:27:47 +0000
Subject: [issue5920] Confusing float formatting for empty presentation type.
In-Reply-To: <1241435439.97.0.212795194169.issue5920@psf.upfronthosting.co.za>
Message-ID: <1241548067.9.0.000406643868161.issue5920@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Committed in py3k r72333 and trunk r72348. I also updated the
documentation. Closing the issue.

----------
components: +Interpreter Core
status: open -> closed

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

From report at bugs.python.org  Tue May  5 20:42:13 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 18:42:13 +0000
Subject: [issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Message-ID: <1241548933.51.0.309417342262.issue1153027@psf.upfronthosting.co.za>


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

Fixed in the Revision 43132.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue May  5 20:43:59 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 18:43:59 +0000
Subject: [issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Message-ID: <1241549039.33.0.944736919701.issue1153027@psf.upfronthosting.co.za>


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

fixed in revision 43132 ( smaller 'r' for the roundup to auto-hyperlink). :)

----------

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

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


Mitchell Model <mlm at acm.org> added the comment:

And, checking the methods of dbm.ndbm, I find get() and setdefault() but
nothing like iterkeys() or iteritems(), just keys().

I think it might also be worth pointing out that a particular variation
of dbm may be chosen to create a database file by calling the
submodule's open function -- dbm.gdbm.open(), dbm.ndbm.open(), or
dbm.dumb.open().

----------

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

From report at bugs.python.org  Tue May  5 20:45:28 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 18:45:28 +0000
Subject: [issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Message-ID: <1241549128.79.0.625294140282.issue1153027@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------

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

From report at bugs.python.org  Tue May  5 20:46:08 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 18:46:08 +0000
Subject: [issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Message-ID: <1241549168.93.0.197478160921.issue1153027@psf.upfronthosting.co.za>


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

Sorry, I meant fixed in revision 72351.

----------

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

From report at bugs.python.org  Tue May  5 20:47:05 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 18:47:05 +0000
Subject: [issue918368] urllib doesn't correct server returned urls
Message-ID: <1241549225.41.0.930878177518.issue918368@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


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

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

From report at bugs.python.org  Tue May  5 20:47:34 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 05 May 2009 18:47:34 +0000
Subject: [issue5861] test_urllib fails on windows
In-Reply-To: <1240883003.46.0.843478025116.issue5861@psf.upfronthosting.co.za>
Message-ID: <1241549254.75.0.84610759196.issue5861@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


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

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

From report at bugs.python.org  Tue May  5 21:06:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 19:06:50 +0000
Subject: [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: <1241550410.31.0.0182447992014.issue5944@psf.upfronthosting.co.za>


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

OS/X needs to be special cased in the tests, since it transforms the
invalid filenames on write.  And if I remember correctly older versions
do something different...throw an error, maybe?

The case where the letter looks the same (at least in my email) but is
apparently different may require some thought, too.

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

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

From report at bugs.python.org  Tue May  5 21:11:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 19:11:29 +0000
Subject: [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: <1241550689.6.0.957352231331.issue5944@psf.upfronthosting.co.za>


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

> The case where the letter looks the same (at least in my email) but is
> apparently different may require some thought, too.

In case it's useful, when I do a list(map(ord, ...)) on those two 
lookalike strings I get (where 'expected' comes from the explicit .decode, 
while 'found' comes from listdir):

expected: [102, 111, 111, 246, 98, 97, 114]
found:    [102, 111, 111, 111, 776, 98, 97, 114]

----------

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

From report at bugs.python.org  Tue May  5 21:21:06 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 05 May 2009 19:21:06 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't
	be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1241551266.69.0.850138680939.issue5504@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Here is a patch for Python trunk (linux only).

----------
Added file: http://bugs.python.org/file13897/issue5504.patch

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

From report at bugs.python.org  Tue May  5 21:42:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 19:42:07 +0000
Subject: [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: <1241552527.49.0.210408352226.issue5944@psf.upfronthosting.co.za>


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

Even better:

>>> for s in map(unicodedata.name, found): print(s)
... 
LATIN SMALL LETTER F
LATIN SMALL LETTER O
LATIN SMALL LETTER O
LATIN SMALL LETTER O
COMBINING DIAERESIS
LATIN SMALL LETTER B
LATIN SMALL LETTER A
LATIN SMALL LETTER R
>>> for s in map(unicodedata.name, expected): print(s)
... 
LATIN SMALL LETTER F
LATIN SMALL LETTER O
LATIN SMALL LETTER O
LATIN SMALL LETTER O WITH DIAERESIS
LATIN SMALL LETTER B
LATIN SMALL LETTER A
LATIN SMALL LETTER R
>>> found == expected
False
>>> unicodedata.normalize('NFC', found) == unicodedata.normalize('NFC', 
expected)
True

So there are two separate issues, both of which just require fixing the 
tests:  one issue is that OS X transforms invalid filenames;  the other is 
that it normalizes valid filenames.

----------

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

From report at bugs.python.org  Tue May  5 21:53:44 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 05 May 2009 19:53:44 +0000
Subject: [issue4875] find_library can return directories instead of files
In-Reply-To: <1231375416.63.0.958079386255.issue4875@psf.upfronthosting.co.za>
Message-ID: <1241553224.36.0.791410532648.issue4875@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Fixed in trunk (rev 72352), release26-maint (rev 72353), py3k (rev
72354), and release30-maint (rev 72355).

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

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

From report at bugs.python.org  Tue May  5 21:56:18 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 05 May 2009 19:56:18 +0000
Subject: [issue1648957] HP-UX:
	_ctypes/libffi/src/ia64/ffi/__attribute__/native cc
Message-ID: <1241553378.22.0.959713470552.issue1648957@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
components:  -Build
stage: test needed -> 

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

From report at bugs.python.org  Tue May  5 22:01:56 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 05 May 2009 20:01:56 +0000
Subject: [issue1581906] test_sqlite fails on OS X if test_ctypes is run
Message-ID: <1241553716.06.0.0420644262282.issue1581906@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

So, should this be closed as some kind of 'works for me' + 'wont fix' +
 'third-party-bug' in Apple's sqlite?

----------

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

From report at bugs.python.org  Tue May  5 22:11:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 20:11:30 +0000
Subject: [issue1581906] test_sqlite fails on OS X if test_ctypes is run
Message-ID: <1241554290.68.0.664775531916.issue1581906@psf.upfronthosting.co.za>


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

Probably.

I do remember investigating this further, but I don't entirely remember 
what I found.  I think Ronald's comment about flat namespaces turned out 
to be highly relevant though.

----------

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

From report at bugs.python.org  Tue May  5 22:28:08 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 May 2009 20:28:08 +0000
Subject: [issue5643] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1238586550.45.0.844379263332.issue5643@psf.upfronthosting.co.za>
Message-ID: <1241555288.71.0.439603761927.issue5643@psf.upfronthosting.co.za>


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

I think the patch is good to go.

----------

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

From report at bugs.python.org  Tue May  5 23:00:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 21:00:21 +0000
Subject: [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: <1241557221.42.0.395135382388.issue5944@psf.upfronthosting.co.za>


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

Here's a patch that fixes the test failures for me.  It's not ideal, 
because it no longer tests that on OS X, it's possible to open a file 
created with an invalid filename, using that same name.

----------
keywords: +patch
Added file: http://bugs.python.org/file13898/issue5944.patch

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

From report at bugs.python.org  Tue May  5 23:00:34 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Tue, 05 May 2009 21:00:34 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241557234.83.0.276883492451.issue5753@psf.upfronthosting.co.za>


Jan Lieskovsky <iankko at seznam.cz> added the comment:

Antoine,

  (re: #msg87083, #msg87084) -- while the API change is acceptable and
reasonable, it doesn't solve the core of the problem. I understand
the change needs to be 'backward compatible' and shouldn't break
the existing Python behavior, but the current proposed patch:

1, doesn't avoid the need to fix the issue (by calling
"PySys_SetArgvEx(argc, argv, 0);") in all current applications embedding
Python,

2, doesn't dismiss the risk of future appearance of application, 
embedding Python interpreter and using it in a vulnerable way
(in fact, all what it does, is adding recommendation / alternative
to use more safer PySys_SetArgv(*, *, 0) for such cases. I don't think
we can just rely on the fact, the developers will use it in a safe
way in the future -- or did I overlooked something?

Wouldn't be possible to fix it 'only in Python' and prevent such
potential future malicious (mis)uses?

To Martin (re: #msg87212):

What's the question of 'security nature' of the issue, Glyph in
message #msg86927 already uncovered potential implications --
if the application was written either 'by accident', or 'by intention',
it shouldn't just allow to execute anything with the privileges of
superuser, and even worse, doing it silently (then the only warranty
for the unprivileged user would be to rely on the fact, the function
was called 'in a safe way' in the application and I suppose such
assumption would completely discourage him from running it).

I recommend the final fix should be applied to all active Python
branches (just comment on second part of Martin's comment).

Regards, Jan.

----------

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

From report at bugs.python.org  Tue May  5 23:09:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 May 2009 21:09:49 +0000
Subject: [issue5899] test_capi crashes when called more than once
In-Reply-To: <1241213907.75.0.583919845233.issue5899@psf.upfronthosting.co.za>
Message-ID: <1241557789.6.0.699442907376.issue5899@psf.upfronthosting.co.za>


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

Fixed in r72357.

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 23:15:39 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 21:15:39 +0000
Subject: [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: <1241558139.11.0.769191545542.issue5944@psf.upfronthosting.co.za>


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

I think skipping the test entirely would be even better on Darwin. The
test is really meant to pass only on systems that treat file names as
uninterpreted byte sequences (as such, it may also fail on Linux if the
file system driver enforces UTF-8).

To skip it, it probably would be best to move it out of the "not win32"
block, and into a "neither win32 nor darwin" block - or use the skipIf
decorator.

----------

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

From report at bugs.python.org  Tue May  5 23:21:33 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 21:21:33 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241558493.91.0.824820745936.issue5799@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Looking at Guido's removal of this back in 1999, he says:
"""
* Lib/ntpath.py:
Withdraw the UNC support from splitdrive().  Instead, a new function
splitunc() parses UNC paths.  The contributor of the UNC parsing in
splitdrive() doesn't like it, but I haven't heard a good reason to
keep it, and it causes some problems.  (I think there's a
philosophical problem -- to me, the split*() functions are purely
syntactical, and the fact that \\foo is not a valid path doesn't mean
that it shouldn't be considered an absolute path.)
"""

Do you have any comment on his philosophical problem?

----------
assignee:  -> eric.smith

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 23:25:46 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 21:25:46 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1241557234.83.0.276883492451.issue5753@psf.upfronthosting.co.za>
Message-ID: <4A00AED7.6060205@v.loewis.de>


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

> What's the question of 'security nature' of the issue, Glyph in
> message #msg86927 already uncovered potential implications --

The question is whether these are theoretical or real problems.
I ran gedit (as proposed by Glyph) under strace(1), and it didn't
try to open any files in the current directory.

----------

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

From report at bugs.python.org  Tue May  5 23:28:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 21:28:31 +0000
Subject: [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: <1241558911.21.0.982558809147.issue5944@psf.upfronthosting.co.za>


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

> I think skipping the test entirely would be even better on Darwin.

Sounds good to me!  Here's a new (one-line) patch, using skipIf.

----------
Added file: http://bugs.python.org/file13899/issue5944_v2.patch

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May  5 23:32:23 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 21:32:23 +0000
Subject: [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: <1241559143.74.0.994005085061.issue5944@psf.upfronthosting.co.za>


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

Fine with me, please apply.

----------
assignee:  -> marketdickinson
resolution:  -> accepted

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

From report at bugs.python.org  Tue May  5 23:35:12 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 21:35:12 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241559312.58.0.0992501922376.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I've never understood what is the "philosophical problem" per se.  It's
clear from his implementation--Guido created "splitunc" when he removed
my patch--that he thinks these should be precise string operations. 
Whereas I propose making these slightly higher-level abstract operations
on "paths" with "drives" (really "mount points").  I think my approach
is more pleasant to use.

As for whether or not "\\foo" should be considered an absolute
path--perhaps my 1999 patch changed this behavior, but this patch does
not.  This:
  >>> import ntpath
  >>> ntpath.isabs("//foo")
  True
is unchanged by the attached patch.  (Or, at the very least, the latest
patch.)

At the time I guess I did a poor job of demonstrating the use case, but
I think the chorus of +1s shows there is one.

On the other hand, I'm not a Windows programmer anymore, and I barely
touch Windows boxes.  I'm doing this out of the kindness of my heart ;)

----------

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

From report at bugs.python.org  Tue May  5 23:37:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 May 2009 21:37:14 +0000
Subject: [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: <1241559434.72.0.580297552749.issue5944@psf.upfronthosting.co.za>


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

Committed, r72359.

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

_______________________________________
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: [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  Tue May  5 23:54:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2009 21:54:34 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1241560474.39.0.817323999163.issue1368247@psf.upfronthosting.co.za>


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

It looks to me like MIMEText doesn't actually support unicode input.  .

One way to get the example to work is to do this:

 MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430'.encode('utf-8'), 'plain', 'utf-8')

The above call produces valid output from as_string:

'Content-Type: text/plain; charset="utf-8"\nMIME-Version:
1.0\nContent-Transfer-Encoding: base64\n\n0LrQuNGA0LjQu9C40YbQsA==\n'

How you'd get it to use 8bit, I have no idea.  Still, I'm inclined to
close this as invalid unless Barry tells me my analysis is wrong.

(CF: http://mg.pov.lt/blog/unicode-emails-in-python for a good example
of handling unicode using the email package, which I found after
figuring out the above.)

Clearly, the documentation of this could be better, but I suspect the
developers would rather spend their time fixing the email module in py3.
 A doc patch would certainly be accepted.  (Maybe someone could ask the
above blogger if we could borrow his example for the docs.)

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending
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/issue1368247>
_______________________________________

From report at bugs.python.org  Tue May  5 23:59:55 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 May 2009 21:59:55 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241560795.12.0.237102105208.issue5799@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee: eric.smith -> 

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 00:15:12 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 22:15:12 +0000
Subject: [issue5721] msi.py still tries to copy non-existent test/README
In-Reply-To: <1239182585.76.0.888462056491.issue5721@psf.upfronthosting.co.za>
Message-ID: <1241561712.85.0.212002479349.issue5721@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r72361, r72362.

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

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 00:16:22 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 22:16:22 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1241561782.12.0.0795510179081.issue4709@psf.upfronthosting.co.za>


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

Lowering the priority. It's too difficult to setup the environment to be
able to reproduce the issue being fixed.

----------
priority: critical -> normal

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 00:31:19 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 05 May 2009 22:31:19 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1241562679.86.0.707694840636.issue3061@psf.upfronthosting.co.za>


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

Is it possible to find out what specific encoding is being used?

In most cases, nl_langinfo(CODESET) would be the right choice, but that
depends on the LC_CTYPE category. If available, wcsftime should be used.

In any case, I think issue5903 and issue5562 are related. We should
close some of them as duplicates.

----------

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

From report at bugs.python.org  Wed May  6 00:32:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 May 2009 22:32:28 +0000
Subject: [issue5630] Create alternative CObject API that is safe and clean
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1241562748.03.0.422832306102.issue5630@psf.upfronthosting.co.za>


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

Applied in r72363.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Wed May  6 00:49:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 May 2009 22:49:58 +0000
Subject: [issue5643] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1238586550.45.0.844379263332.issue5643@psf.upfronthosting.co.za>
Message-ID: <1241563798.78.0.773721015285.issue5643@psf.upfronthosting.co.za>


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

Applied in r72365.

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

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

From report at bugs.python.org  Wed May  6 01:00:09 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 05 May 2009 23:00:09 +0000
Subject: [issue5846] Deprecate obsolete functions in unittest
In-Reply-To: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za>
Message-ID: <1241564409.11.0.779371397916.issue5846@psf.upfronthosting.co.za>


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

So it turns out that unittest.makeSuite is used about 100 times
throughout the standard library tests.

More than half the time it can be replaced with
unittest.TestLoader().loadTestsFromTestCase(...)

Some of the other times a loader needs to be constructed and then a
testMethodPrefix of 'Check' set (yuck!).

I'm about halfway through a patch that does this. Think it is worth
continuing or shall I drop it. I don't mind doing it so long as
*someone* thinks it is worthwhile... :-)

(I haven't yet checked for getTestCaseNames but I imagine there will be
a bunch of these to fix as well.)

Another possibility is to move the functions into test_support
(deprecating first) where at least they are out of unittest.

----------

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

From report at bugs.python.org  Wed May  6 01:03:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 May 2009 23:03:39 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1241557234.83.0.276883492451.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241564731.10795.12.camel@localhost>


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

Hello Jan,

> 1, doesn't avoid the need to fix the issue (by calling
> "PySys_SetArgvEx(argc, argv, 0);") in all current applications embedding
> Python,

As you said yourself, we don't want to break backwards compatibility for
C API users -- especially between two minor versions such as 2.6.2 and
2.6.3. The current behaviour is certainly by design, otherwise it
wouldn't be so complicated.

Besides, the patch you proposed is fragile as it relies on a hard coded
value for the executable name, and it also complexifies the behaviour
even more. I don't think we should apply it in core Python. On the other
hand, adding an /explicit/ option in the API minimizes the risk for
confusion and signals clearly that an alternative is available.

> I don't think
> we can just rely on the fact, the developers will use it in a safe
> way in the future

Well, you can always shoot yourself in the foot in C, even without using
the Python API. The patch just provides a practical way for
Python-embedding applications to be safer. Then, it's up to application
developers to do their job.

> Wouldn't be possible to fix it 'only in Python' and prevent such
> potential future malicious (mis)uses?

AFAICT, not without risking breaking compatibility for perfectly
well-behaved apps which would rely on the current behaviour.

----------

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

From report at bugs.python.org  Wed May  6 01:08:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 May 2009 23:08:23 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241564903.55.0.272605875583.issue5753@psf.upfronthosting.co.za>


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

> The question is whether these are theoretical or real problems.
> I ran gedit (as proposed by Glyph) under strace(1), and it didn't
> try to open any files in the current directory.

You have to use a Python-written gedit plugin for that to happen. For
example, if I enable the "Python console" plugin, I get the following
lines in strace:

17569:open("gconf.so", O_RDONLY)              = -1 ENOENT (No such file
or directory)
17570:open("gconfmodule.so", O_RDONLY)        = -1 ENOENT (No such file
or directory)
17571:open("gconf.py", O_RDONLY)              = -1 ENOENT (No such file
or directory)
17572:open("gconf.pyc", O_RDONLY)             = -1 ENOENT (No such file
or directory)

----------

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

From report at bugs.python.org  Wed May  6 01:23:57 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 05 May 2009 23:23:57 +0000
Subject: [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: [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 02:07:22 2009
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 06 May 2009 00:07:22 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241568441.89.0.421225229068.issue5799@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Should the DeprecationWarning for splitunc be a PendingDeprectionWarning
for 3.1 and get 'upgraded' in 3.2?

----------

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

From report at bugs.python.org  Wed May  6 02:17:54 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 06 May 2009 00:17:54 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241569074.74.0.633904705812.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I don't know what would be proper, but I'm happy to change it if you
think that's best.

----------

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

From =?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 03:09:02 2009
From: =?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?=C3=89ric_Araujo_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 01:09:02 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1241572142.28.0.725254023221.issue5922@psf.upfronthosting.co.za>


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

Nitpicking: I suggest renaming one class used in testing from CtorRaises
to InitRaises, since __init__ is not a constructor (and the meaning of
?Ctor? is not that obvious :)

----------
nosy: +Merwok

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

From report at bugs.python.org  Wed May  6 04:40:06 2009
From: report at bugs.python.org (Senthil)
Date: Wed, 06 May 2009 02:40:06 +0000
Subject: [issue1368312] fix for scheme identification in urllib2?
Message-ID: <1241577606.15.0.872224491008.issue1368312@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

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

From report at bugs.python.org  Wed May  6 06:44:04 2009
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 06 May 2009 04:44:04 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241585043.82.0.82721652141.issue5799@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

This looks good to me.

My take on Guido's earlier notes are that they caused a problem in
practice, and the philosophical concerns added justification for
removing it.  I'm yet to meet a Windows user with a philosophical
objection to this.

I'm attaching a new patch; I've added a news entry, changed to a
PendingDeprecation warning and moved the import of the warnings module
to the splitunc function to avoid extra import overhead, even if tiny. 
Could anyone still awake and available please have a quick review of the
news entry and my change?

----------
assignee:  -> mhammond
Added file: http://bugs.python.org/file13902/markh.ntpath.r72374.diff

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

From report at bugs.python.org  Wed May  6 07:34:06 2009
From: report at bugs.python.org (Cournapeau David)
Date: Wed, 06 May 2009 05:34:06 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1241588046.15.0.223439230568.issue4709@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

The toolchain is difficult to build, but the patch is easy to review, it
just moves the MS_WIN64 outside the MS compiler specific part. If it
does not break the MS toolchain (the one used to build the official
python), I don't see the problem.

I can make the toolchain available to you as a tarball, though, so that
you can easily test from a windows command shell without having to
install anything.

----------

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

From report at bugs.python.org  Wed May  6 07:34:52 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Wed, 06 May 2009 05:34:52 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241588092.1.0.998925789871.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Committed the initial patch in r72375 for trunk and r72376 for py3k.

Any other branches that would need the merge? 3.0?

----------
resolution:  -> accepted
stage: test needed -> committed/rejected
status: open -> pending

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 09:25:29 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 07:25:29 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241594729.44.0.243000308894.issue5753@psf.upfronthosting.co.za>


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

I wonder why all these applications call PySys_SetArgv at all if they
don't have any arguments to set. In the gedit case, I just removed the
call from gedit, and it seems to work fine (sys.argv will be an empty list).

----------

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

From report at bugs.python.org  Wed May  6 09:26:10 2009
From: report at bugs.python.org (Cournapeau David)
Date: Wed, 06 May 2009 07:26:10 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1241594770.3.0.60890612738.issue4709@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

Ok, it looks like following gcc 4.4.0 release, there is an installer for
the whole toolchain:

http://www.equation.com/servlet/equation.cmd?call=fortran

This installs gcc (C+Fortran+C++ compilers, the download is ~ 40 Mb),
and it can be used from the command line as conventional mingw32.
Hopefully, this should make the patch much easier to test.

----------

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

From report at bugs.python.org  Wed May  6 09:32:32 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 06 May 2009 07:32:32 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241595152.69.0.216130272236.issue5799@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I tested your patch and it looks good to me.  I didn't get the
deprecation warning on ntpath.splitunc unless I disabled all warnings.

----------

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 09:32:41 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: Wed, 06 May 2009 07:32:41 +0000
Subject: [issue5940] Wrong type check in check_library_list
In-Reply-To: <1241512069.38.0.233347773971.issue5940@psf.upfronthosting.co.za>
Message-ID: <1241595161.68.0.0521687988436.issue5940@psf.upfronthosting.co.za>


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

fixed in r72379 

Thanks David !

Notice that this bug exists in Python 3.0 too unfortunately.

So I have applied the fix in the 3.0 release branch as well (r72380)

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

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

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 09:34:22 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: Wed, 06 May 2009 07:34:22 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241595262.28.0.550158549738.issue5941@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> critical

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

From report at bugs.python.org  Wed May  6 09:35:51 2009
From: report at bugs.python.org (Cournapeau David)
Date: Wed, 06 May 2009 07:35:51 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241595351.53.0.0272590953117.issue5941@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

The bug is also present in python 2.7a

----------
versions: +Python 2.7, Python 3.0

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 09:38:31 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 07:38:31 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1241588046.15.0.223439230568.issue4709@psf.upfronthosting.co.za>
Message-ID: <4A013E6C.80700@v.loewis.de>


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

> The toolchain is difficult to build, but the patch is easy to review, it
> just moves the MS_WIN64 outside the MS compiler specific part. If it
> does not break the MS toolchain (the one used to build the official
> python), I don't see the problem.

As a principle, I always try to reproduce a problem when reviewing a
patch. In many cases, doing so reveals insights into the actual problem,
and leads to a different patch.

That the patch is "harmless" is not a convincing reason to apply it.

> I can make the toolchain available to you as a tarball, though, so that
> you can easily test from a windows command shell without having to
> install anything.

That would be nice.

----------

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 09:39:06 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 07:39:06 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241595546.76.0.559219590203.issue1443504@psf.upfronthosting.co.za>


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

It looks like a bug fix to me - so it would apply to all four active
branches.

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

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

From report at bugs.python.org  Wed May  6 09:48:23 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 06 May 2009 07:48:23 +0000
Subject: [issue5947] Deprecate CObject
In-Reply-To: <1241567133.24.0.131826723063.issue5947@psf.upfronthosting.co.za>
Message-ID: <1241596103.7.0.00921332885306.issue5947@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

It's 12:45am, and I've already learned my New Thing for the day.  I
didn't know about PendingDeprecationWarning.  That's just exactly what
CObject should throw.

Attached is a new patch.  The two CObject constructors now throw a
PendingDeprecationWarning every time they are called.

Tested manually: I create CObjects and nothing happens.  I then run
warnings.resetwarnings() and create CObjects and see a
PendingDeprecationWarning.  Perfect!

----------
Added file: http://bugs.python.org/file13903/lch.deprecatecobject.r72374.diff

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

From report at bugs.python.org  Wed May  6 10:06:12 2009
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 06 May 2009 08:06:12 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241597172.85.0.838943921888.issue5799@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Checked into the trunk as r72387 (after normalizing whitespace in
ntpath.py after the precommit-hook failed).   Thanks Larry and Eric!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5799>
_______________________________________

From report at bugs.python.org  Wed May  6 10:17:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 May 2009 08:17:38 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241597858.78.0.750914301331.issue5933@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For the second, I don't understand why you want to
> compare the return result with RLIM_INFINITY:  PyInt_AsLong
> returns -1 to signal failure;  is there some guarantee that
> RLIM_INFINITY == -1 if it's defined?

rlim_t is an unsigned type. The idea of sign_warning_resource.patch 
was to make gcc quiet about signed/unsigned comparaisons.

RLIM_INFINITY is defined as (rlim_t)-1. But it looks that it's not 
clear, so I wrote another patch to fix the warnings.

----------
Added file: http://bugs.python.org/file13904/sign_warning_resource-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5933>
_______________________________________

From report at bugs.python.org  Wed May  6 10:17:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 May 2009 08:17:42 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241597862.61.0.807010734856.issue5933@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file13884/sign_warning_resource.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5933>
_______________________________________

From report at bugs.python.org  Wed May  6 10:17:45 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 May 2009 08:17:45 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241597865.0.0.929693989656.issue5933@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file13883/sign_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5933>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 10:24:22 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: Wed, 06 May 2009 08:24:22 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241598262.37.0.863315582486.issue5941@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

what is your traceback ? I want to make sure I have the same in the 
test I built.

Also, just before the traceback, can you tell me the exact command
that is spawned in ccompiler.py line 1036.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5941>
_______________________________________

From report at bugs.python.org  Wed May  6 10:27:01 2009
From: report at bugs.python.org (Cournapeau David)
Date: Wed, 06 May 2009 08:27:01 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241598421.73.0.465438452072.issue5941@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

You can see the traceback in this recent email:

http://mail.python.org/pipermail/python-list/2009-May/712106.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5941>
_______________________________________

From report at bugs.python.org  Wed May  6 10:27:59 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Wed, 06 May 2009 08:27:59 +0000
Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails
Message-ID: <1241598479.13.0.352821989507.issue1443504@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Committed in r72381 and r72395.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1443504>
_______________________________________

From report at bugs.python.org  Wed May  6 10:32:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 May 2009 08:32:33 +0000
Subject: [issue5946] Fix spelling error in Capsule docs
In-Reply-To: <1241565836.19.0.75151730521.issue5946@psf.upfronthosting.co.za>
Message-ID: <1241598753.93.0.0238142374796.issue5946@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r72396.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5946>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 10:42: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: Wed, 06 May 2009 08:42:10 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241599330.8.0.15168083791.issue5941@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok I am able to reproduce it. We can't change AR in the makefile,
so I think the best way is to add like you said the -cr option
in Python Makefile under a new variable, then use it in customize_compiler

I'll ask on python-dev because I am new to the Makefile.

A turnaround until then is to set AR with the correct option 
in os.environ['AR']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5941>
_______________________________________

From report at bugs.python.org  Wed May  6 10:48:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 May 2009 08:48:07 +0000
Subject: [issue5947] Deprecate CObject
In-Reply-To: <1241567133.24.0.131826723063.issue5947@psf.upfronthosting.co.za>
Message-ID: <1241599687.58.0.410625912104.issue5947@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r72397.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5947>
_______________________________________

From report at bugs.python.org  Wed May  6 10:51:17 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 06 May 2009 08:51:17 +0000
Subject: [issue5799] Change ntpath functions to implicitly support UNC paths
In-Reply-To: <1240225634.02.0.80774698084.issue5799@psf.upfronthosting.co.za>
Message-ID: <1241599877.09.0.26341710127.issue5799@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Thanks for looking at this, Mark. If we could only assign issues to
Python 3.2 and 3.3 to change the pending deprecation warning to a real
one, and to remove the function entirely, we'd be all set! I'm always
worried we'll forget these things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5799>
_______________________________________

From report at bugs.python.org  Wed May  6 11:05:20 2009
From: report at bugs.python.org (Guillaume Desmottes)
Date: Wed, 06 May 2009 09:05:20 +0000
Subject: [issue1194378] sendmsg() and recvmsg() for C socket module
Message-ID: <1241600720.32.0.979378489671.issue1194378@psf.upfronthosting.co.za>


Changes by Guillaume Desmottes <gdesmott at gnome.org>:


----------
nosy: +gdesmott

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1194378>
_______________________________________

From report at bugs.python.org  Wed May  6 12:53:32 2009
From: report at bugs.python.org (Stefan Ring)
Date: Wed, 06 May 2009 10:53:32 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
	faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1241607212.55.0.469751660203.issue5322@psf.upfronthosting.co.za>


Changes by Stefan Ring <stefanrin at gmail.com>:


----------
nosy: +Ringding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Wed May  6 13:30:47 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 06 May 2009 11:30:47 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241609447.26.0.22204507126.issue5941@psf.upfronthosting.co.za>


Changes by Floris Bruynooghe <floris.bruynooghe at gmail.com>:


----------
nosy: +flub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5941>
_______________________________________

From report at bugs.python.org  Wed May  6 14:28:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 May 2009 12:28:54 +0000
Subject: [issue1209447] os.path.join() fails if 2nd arg is a UNC path
Message-ID: <1241612934.32.0.981567744115.issue1209447@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Seems to be fixed in python3.1. See #5799. This is not backported for
2.x yet. (Or it won't happen)

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1209447>
_______________________________________

From report at bugs.python.org  Wed May  6 14:37:14 2009
From: report at bugs.python.org (Brian Mearns)
Date: Wed, 06 May 2009 12:37:14 +0000
Subject: [issue5887] mmap.write_byte out of bounds - no error,
	position gets screwed up
In-Reply-To: <1241116100.06.0.276322653454.issue5887@psf.upfronthosting.co.za>
Message-ID: <1241613434.56.0.0885804538769.issue5887@psf.upfronthosting.co.za>


Brian Mearns <bmearns at ieee.org> added the comment:

Confirmed fixed in python 2.6.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5887>
_______________________________________

From report at bugs.python.org  Wed May  6 14:51:32 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 May 2009 12:51:32 +0000
Subject: [issue5887] mmap.write_byte out of bounds - no error,
	position gets screwed up
In-Reply-To: <1241116100.06.0.276322653454.issue5887@psf.upfronthosting.co.za>
Message-ID: <1241614292.88.0.401610404531.issue5887@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for response. I'll close this entry.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5887>
_______________________________________

From report at bugs.python.org  Wed May  6 15:01:19 2009
From: report at bugs.python.org (Brian Mearns)
Date: Wed, 06 May 2009 13:01:19 +0000
Subject: [issue5887] mmap.write_byte out of bounds - no error,
	position gets screwed up
In-Reply-To: <1241614292.88.0.401610404531.issue5887@psf.upfronthosting.co.za>
Message-ID: <4df3a1330905060601l6d810cdeuc89bc0bf876d291b@mail.gmail.com>


Brian Mearns <bmearns at ieee.org> added the comment:

On Wed, May 6, 2009 at 8:51 AM, Hirokazu Yamamoto
<report at bugs.python.org> wrote:
>
> Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:
>
> Thank you for response. I'll close this entry.
>
> ----------
> resolution: ?-> out of date
> status: open -> closed
>

Ok, thanks. I wasn't sure if I should close it or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5887>
_______________________________________

From report at bugs.python.org  Wed May  6 15:16:25 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 06 May 2009 13:16:25 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1241615785.46.0.858076015478.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked in to py3k in 72398. I'm reconsidering whether to make this
change in 2.7. I might make the change there, I'll have to check on the
impacts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

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: [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 15:42:33 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 06 May 2009 13:42:33 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241617353.08.0.16356945794.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

@Francesco Sechi: Would it not just require a minimal change to the
_write_data() method? Something along the lines of (sorry, no Python
expert, maybe I am way off):

def _write_data(writer, data, is_attrib=False):
    "Writes datachars to writer."
    if is_attrib: 
        data = data.replace("\r", "&#13;").replace("\n", "&#10;")
    data = data.replace("&", "&amp;").replace("<", "&lt;")
    data = data.replace("\"", "&quot;").replace(">", "&gt;")
    writer.write(data)

and in Element.writexml():

    #[...]
    for a_name in a_names:
        writer.write(" %s=\"" % a_name)
        _write_data(writer, attrs[a_name].value, True)
    #[...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May  6 15:45:56 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 06 May 2009 13:45:56 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241617556.92.0.487221090334.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Of course it should be:

def _write_data(writer, data, is_attrib=False):
    "Writes datachars to writer."
    data = data.replace("&", "&amp;").replace("<", "&lt;")
    data = data.replace("\"", "&quot;").replace(">", "&gt;")
    if is_attrib: 
        data = data.replace("\r", "&#13;").replace("\n", "&#10;")
    writer.write(data)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May  6 16:19:43 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Wed, 06 May 2009 14:19:43 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241619583.78.0.478493596417.issue5948@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

I can verify this on Vista.

2.5 gives:

>>> from locale import setlocale, LC_ALL
>>> setlocale(LC_ALL, "fr")
'French_France.1252'

Whereas 2.6 fails.

There is no difference between 2.5's and 2.6's PyLocale_setlocale() from
what I can see in Modules/_localemodule.c.
Also Lib/locale.py's setlocale() in both versions is identical from what
I can see.

----------
nosy: +asmodai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 16:45:29 2009
From: =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 14:45:29 +0000
Subject: [issue3739] unicode-internal encoder reports wrong length
In-Reply-To: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>
Message-ID: <1241621129.56.0.39111967166.issue3739@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Checked in:
r72404,72406 (trunk)
r72408 (py3k)

As IMHO this is somewhat between a feature and a bugfix, I didn't check
it into release26-maint and release30-maint.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3739>
_______________________________________

From report at bugs.python.org  Wed May  6 17:14:03 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 May 2009 15:14:03 +0000
Subject: [issue3739] unicode-internal encoder reports wrong length
In-Reply-To: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>
Message-ID: <1241622843.32.0.871522233841.issue3739@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I didn't check it into release26-maint and release30-maint.

I agree and anyway this encoder is not really important (it looks to 
be unused...). Thanks for the commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3739>
_______________________________________

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: [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:27:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 May 2009 16:27:25 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241627245.66.0.535563420754.issue5948@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From report at bugs.python.org  Wed May  6 18:28:55 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 May 2009 16:28:55 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241627335.99.0.71839864347.issue5933@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, that looks better.

PS: Do not remove applied patches.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5933>
_______________________________________

From report at bugs.python.org  Wed May  6 18:45:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 May 2009 16:45:10 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241628310.98.0.109479510618.issue5933@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PS: Do not remove applied patches.

Oh ok, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5933>
_______________________________________

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: [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  Wed May  6 18:54:56 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 May 2009 16:54:56 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241628896.89.0.247707304137.issue5948@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Did you build python from source? Or did you download official binary
distribution? If latter, Python2.5 was built with VC7, and Python2.6 is
built with VC9. Probably difference of behavior comes from difference of
version of msvcrt.

I ran following codes from my python2.6 built from source with VC6, and
I succeeded to set locale.

Python 2.6.2c1 (release26-maint, Apr 11 2009, 07:01:50) [MSC v.1200 32
bit (Inte
l)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(4, "ja")
'Japanese_Japan.932'
>>> locale.setlocale(4, "fr")
'French_France.1252'

----------
assignee: loewis -> 
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From report at bugs.python.org  Wed May  6 18:58:58 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 May 2009 16:58:58 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241629138.39.0.903890516707.issue5948@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
assignee:  -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From report at bugs.python.org  Wed May  6 19:45:37 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Wed, 06 May 2009 17:45:37 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241631937.33.0.367411700162.issue5948@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

My tests were with official distributions.

Yamamoto-san, thank you for your testing. I was thinking it might have
been something to do with changed semantics, but I am happy you saved me
the time from having to compile.

Looking at the documentation for setlocale() in VS6
(http://msdn.microsoft.com/en-us/library/aa272906(VS.60).aspx) and 7
(http://msdn.microsoft.com/en-us/library/x99tb11d(VS.71).aspx) it seems
that the behaviour in VS6 (and thus Python 2.5) was flawed. The
supported language options are listed at
http://msdn.microsoft.com/en-us/library/aa246450(VS.60).aspx and they do
not list a "fr" combination. It seems the possibility of "fr" working
might have been a remnant or a bug. The appropriate language designation
should have been "fra" for the default French locale.

>From my 2.6 interpreter:

>>> setlocale(LC_ALL, "fra")
'French_France.1252'

So this is all intended behaviour and not a bug with Python. As such I
propose to close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From report at bugs.python.org  Wed May  6 20:58:08 2009
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Wed, 06 May 2009 18:58:08 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241636288.86.0.314093976544.issue5753@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at divmod.com> added the comment:

It suggests to me that somewhere there's some documentation, or an
example, that says "this is the right way to embed python, call this
function".

If the right thing to do is to just not call the function at all, we
need to get that knowledge out there into the embedding community and
publicize this issue.  Perhaps a doc bug?  PySys_SetArgvEx seems like it
might be a good idea for applications which do still want to set the
argument list without the sys.path implications, but a quick perusal of
the sources of plugins for the affected applications suggests that none
of them need it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Wed May  6 21:03:04 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Wed, 06 May 2009 19:03:04 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241636584.67.0.288721031608.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

This patch changes the log.py in order to make use of the logging 
infrastructure.

There are few point tough worth of mention.

There're two separate stages when log.py is used:
  a) during the python interpreter build (let's call it bootstrap) 
  b) for every python setup.py cycle

During the bootstrap log.py doesn't seem have access to the logging 
module
(at least on the CentOS/Redhat/Suse build systems, but I assume is true 
for 
other platforms): in this case a fallback minimal logging is in place.

Once the python is in place (eg. installed) it can make use of the true 
logging: this happen when  python setup.py <cmd> is used to create a 
python module.

A python intepreter built with the patch (from the latest python build) 
is hosted in:

http://download.opensuse.org/repositories/home:/cavallo71:/python-opt

----------
nosy: +cavallo71
type:  -> feature request
versions:  -Python 3.1
Added file: http://bugs.python.org/file13906/issue3992.remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Wed May  6 22:29:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 May 2009 20:29:55 +0000
Subject: [issue5847] IDLE/Win Installer: drop -n switch for 2.7/3.1;
	install 3.1 as idle3
In-Reply-To: <1240715305.76.0.471826786959.issue5847@psf.upfronthosting.co.za>
Message-ID: <1241641795.8.0.530062624077.issue5847@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Closing since this problem seems to be fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5847>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May  6 22:37:55 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: Wed, 06 May 2009 20:37:55 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241642275.05.0.399793131743.issue3992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

After more thinking, I think we can use a better strategy:
 
- adding a deprecate warning inside the log module 
  and keep the code as it is
- set in the __init__ module the regular logger 
- change every call in distutils from the old log system to the new

now for the access problem, can you explain me when+how it happens 
exactly ?

btw, in your patch: 

- you have a raise 
- "except:" should be "except ImportError:"
- in _log, Logger.level should be self.level, same for Logger.stream
- I don't see why LOG, DEBUG etc is defined only in the try:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 23:05:40 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 21:05:40 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241643940.13.0.113238162.issue5948@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May  6 23:10:43 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 06 May 2009 21:10:43 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1241636288.86.0.314093976544.issue5753@psf.upfronthosting.co.za>
Message-ID: <4A01FCCF.4070600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It suggests to me that somewhere there's some documentation, or an
> example, that says "this is the right way to embed python, call this
> function".

That may be an explanation. However, it would be immensely useful
to know for sure, from the original authors of one or two such
applications. Perhaps there is some issue that I'm missing (e.g.
too much stuff crashes if sys.argv is empty - but what stuff
could that be?)

IOW, I *really* want to understand what's happening before fixing
it. This is a security issue, after all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Wed May  6 23:16:27 2009
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Wed, 06 May 2009 21:16:27 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241644587.4.0.46404444717.issue5753@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at divmod.com> added the comment:

> IOW, I *really* want to understand what's happening before fixing
> it. This is a security issue, after all.

Agreed.  Does anyone currently subscribed to this ticket know the author
of such an application?  It would be very helpful to have them involved
in the discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Wed May  6 23:30:36 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 May 2009 21:30:36 +0000
Subject: [issue5948] setlocale regression
In-Reply-To: <1241616175.88.0.154367194542.issue5948@psf.upfronthosting.co.za>
Message-ID: <1241645436.79.0.700075192073.issue5948@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as "won't fix", then.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5948>
_______________________________________

From report at bugs.python.org  Wed May  6 23:31:03 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 06 May 2009 21:31:03 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241645463.17.0.640393503537.issue5753@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

gedit does it here:

http://git.gnome.org/cgit/gedit/tree/plugin-loaders/python/gedit-plugin-
loader-python.c#n542

I've emailed the file's author (Jesse) out of the blue to see if he knows 
why PySys_SetArgv() was called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Wed May  6 23:47:32 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Wed, 06 May 2009 21:47:32 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241646452.15.0.812119125303.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

Don't worry, I'm a newer too.
No, your solution does not work, because the method you refer
(_write_data) is called by the toxml() function, but the newline is
replaced with a whitespace by the parsestring() function. The
parsestring function, as I already said, refers to the 'expat' module,
that is very complex (for me).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Thu May  7 00:12:26 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Wed, 06 May 2009 22:12:26 +0000
Subject: [issue5762] AttributeError: 'NoneType' object has no attribute
	'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1241647946.08.0.507512047142.issue5762@psf.upfronthosting.co.za>


Changes by Francesco Sechi <francesco.sechi at iet.unipi.it>:


----------
nosy: +sechi_francesco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________

From report at bugs.python.org  Thu May  7 00:14:02 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Wed, 06 May 2009 22:14:02 +0000
Subject: [issue5762] AttributeError: 'NoneType' object has no attribute
	'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1241648042.82.0.386125555708.issue5762@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

I'm not able to reproduce the issue. Why don't you submit the unit test
that generates the problem? Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________

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: [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 01:47:05 2009
From: report at bugs.python.org (jal)
Date: Wed, 06 May 2009 23:47:05 +0000
Subject: [issue5951] email.message : get_payload args's documentation is
	confusing
In-Reply-To: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>
Message-ID: <1241653625.45.0.0128220688926.issue5951@psf.upfronthosting.co.za>


Changes by jal <loic.jaquemet+python at gmail.com>:


----------
versions: +Python 2.4, Python 2.5, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5951>
_______________________________________

From report at bugs.python.org  Thu May  7 03:05:44 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Thu, 07 May 2009 01:05:44 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241658344.83.0.890227143856.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Hi Tarek,
I agree that a change in that module is "risky" but a warning won't 
solve the main problem in the long run: anyway I'm not able to comment 
about the best strategy.

Now the access problem:

If an import logging is put into the log.py the (python) build fails 
complaining the missing time module (upon which logging depends): this 
happens during the bootstrap phase (the lib-dynload is not in the path 
unless changes to the build system).

This is shown in the suse build server where python gets compiled from 
scratch without a previously installed python (contrary to what usually 
happen on a normal system).

Attached there's the build error using a minimal log.py (susebuild.log).


About my patch:


 - removed the raise
 - now it catches only the ImportError
 - The Logger.stream (as the _log) is a "static" and it should really
     belong to all the classes not a particular instance: anyway
     this is used just during the bootstrap so it needs to provide
     a bare minimum support;)
 - INFO/DEBUG/etc are defined there because they're not
     used during the bootstrap (correctly, IMHO). If I had no fear
     to break the other modules I'd removed them from there as well:
     I haven't seen them used elsewhere.

PS. I'm waiting for the build to complete in order to confirm if 
everything works fine.

----------
Added file: http://bugs.python.org/file13907/susebuild.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu May  7 03:07:45 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Thu, 07 May 2009 01:07:45 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241658465.71.0.0499988196575.issue3992@psf.upfronthosting.co.za>


Changes by Antonio Cavallo <a.cavallo at cavallinux.eu>:


Added file: http://bugs.python.org/file13908/issue3992.remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu May  7 03:07:56 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Thu, 07 May 2009 01:07:56 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241658476.37.0.708223565141.issue3992@psf.upfronthosting.co.za>


Changes by Antonio Cavallo <a.cavallo at cavallinux.eu>:


Removed file: http://bugs.python.org/file13906/issue3992.remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu May  7 03:46:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 May 2009 01:46:36 +0000
Subject: [issue5951] email.message : get_payload args's documentation is
	confusing
In-Reply-To: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>
Message-ID: <1241660796.89.0.985246934532.issue5951@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The answer is that you do msg.get_payload(decode=True).  The doc needs
to be changed over to use keyword argument specification syntax, which I
think would make that obvious.

----------
nosy: +r.david.murray
versions:  -Python 2.4, Python 2.5

_______________________________________
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: [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:25 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 07 May 2009 03:19:25 +0000
Subject: [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 05:28:32 2009
From: report at bugs.python.org (Mike Miller)
Date: Thu, 07 May 2009 03:28:32 +0000
Subject: [issue5884] pydoc to return error status code
In-Reply-To: <1241053592.21.0.872598622661.issue5884@psf.upfronthosting.co.za>
Message-ID: <1241666912.27.0.415602934552.issue5884@psf.upfronthosting.co.za>


Mike Miller <python.org at mgmiller.net> added the comment:

Ahh, I see ... I didn't explain my issue with much depth in haste.

I don't usually run the test suite when I am in the process of updating
code or docs, only when I'm done, then I check it in.

So I was updating the docs and running pydoc with a local batch file and
proofreading the html output.  If there was an error, the file seem to
update.  

You are right it won't happen in the build process after all, but rather
when I am making repetitive changes locally and using the command line.

I might look into doing it myself, although not sure when I'll have time
to get to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5884>
_______________________________________

From report at bugs.python.org  Thu May  7 06:24:14 2009
From: report at bugs.python.org (Rod Morehead)
Date: Thu, 07 May 2009 04:24:14 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1241670254.93.0.0473609193406.issue5949@psf.upfronthosting.co.za>


Rod Morehead <rmore at rmore.net> added the comment:

Isn't the call to read(1) blocking in this case?

If so the only reason it should spin would be if it returned an empty 
string representing EOF.

Couldn't we just add a check for an empty string and, if found, raise an 
EOF exception?

----------
nosy: +rmore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

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: [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 09:44:09 2009
From: report at bugs.python.org (djc)
Date: Thu, 07 May 2009 07:44:09 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1241682249.9.0.776229835879.issue1731717@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Thu May  7 10:24:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 May 2009 08:24:25 +0000
Subject: [issue5846] Deprecate obsolete functions in unittest
In-Reply-To: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za>
Message-ID: <1241684665.28.0.102364242104.issue5846@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm sure Gerhard wouldn't say no to changing the sqlite3 test prefix to
"test_"...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5846>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May  7 10:31:42 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: Thu, 07 May 2009 08:31:42 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241685102.58.0.712399082618.issue3992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I still don't see the need to :

- rename Log to Logger
- remove DEBUG, INFO, WARN, ERROR, FATAL from the module

In the next version of python we will have to keep them 
in any case and add a deprecation warning
because third party tools might use them.

The only thing we have to add is the "logger" global variable that
will let us use the logging module (protected as you said by the 
ImportError


so basically:

try:
  import logging
  logger = _global_log = logging.getLogger('distutils')
except ImportError:
  logger = _global_log = Log()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu May  7 11:10:31 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 09:10:31 +0000
Subject: [issue5918] test_parser crashes when run after some other tests
In-Reply-To: <1241395274.73.0.21825310934.issue5918@psf.upfronthosting.co.za>
Message-ID: <1241687431.38.0.915898539166.issue5918@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's actually an array bounds read error in parsermodule.c::validate_try.
Purify detects it, if you disable pymalloc; distutils is innocent. 

Patch attached.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file13910/parser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5918>
_______________________________________

From report at bugs.python.org  Thu May  7 11:35:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 09:35:07 +0000
Subject: [issue5952] AttributeError exception in urllib.urlopen
In-Reply-To: <1241662361.32.0.52605331473.issue5952@psf.upfronthosting.co.za>
Message-ID: <1241688907.18.0.541980317058.issue5952@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, we need more information to diagnose the problem.
What did you try? Can you provide a minimal example?

Does this reproduce with newer python versions? 2.4 is quite an old
version and will not be corrected.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5952>
_______________________________________

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: [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 13:32:05 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 07 May 2009 11:32:05 +0000
Subject: [issue5442] [3.1alpha1, 2,
	beta1] test_importlib fails on Mac OSX 10.5.6
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241695925.32.0.953144794121.issue5442@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Fails in beta1.

----------
title: [3.1alpha1,2] test_importlib fails on Mac OSX 10.5.6 -> [3.1alpha1,2,beta1] test_importlib fails on Mac OSX 10.5.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Thu May  7 13:33:51 2009
From: report at bugs.python.org (Cournapeau David)
Date: Thu, 07 May 2009 11:33:51 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241696031.72.0.207310156322.issue5941@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

Ok, here is a patch which fixes the issue while retaining the AR
customization. Here is what it does:

 - configure defines both AR and ARFLAGS in the configure script, and
those are used in the Makefile
 - ARFLAGS is used instead of the harcoded rc (rc is the default value
for ARFLAGS in configure)
 - Both AR and ARFLAGS are used in customize_compiler in distutils. If
any of them is customized from the environment, they are overriden.

Some examples:
 - default: nothing changes, except that archiver is set to ar rc
instead of ar in customize_compiler, thus build_clib is not broken anymore
 - setting AR/ARFLAGS in configure: those are used in the python build
 - ARFLAGS=cru python setup.py build_clib will use ar cru instead of ar
cr for libraries.

The only thing I am a bit unsure is that instead of ar -cr, we have ar
cr used as archiver in distutils. Since ac cr is currently used in the
python makefile, I guess most unixes understand ar cr, though.

----------
keywords: +patch
Added file: http://bugs.python.org/file13911/bug_5941.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5941>
_______________________________________

From report at bugs.python.org  Thu May  7 13:42:46 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 07 May 2009 11:42:46 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241696566.65.0.352136255352.issue5798@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Still fails in 3.1 beta1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 13:45:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 May 2009 11:45:53 +0000
Subject: [issue5955] aifc: close() does not close the underlying file
In-Reply-To: <1241690557.41.0.153347725808.issue5955@psf.upfronthosting.co.za>
Message-ID: <1241696753.41.0.874974475096.issue5955@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r72422.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5955>
_______________________________________

From report at bugs.python.org  Thu May  7 14:05:08 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 12:05:08 +0000
Subject: [issue5955] aifc: close() does not close the underlying file
In-Reply-To: <1241690557.41.0.153347725808.issue5955@psf.upfronthosting.co.za>
Message-ID: <1241697908.05.0.883608999452.issue5955@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, but the problem still exists.
self._file is a chunk.Chunk object, and its close() method does nothing.

Adding "self.file = None" at the end of chunk.Chunk.close() helps, even
if this relies on reference counting to close the file.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5955>
_______________________________________

From report at bugs.python.org  Thu May  7 14:09:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 12:09:45 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241698185.46.0.114653486371.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I tried to track this down, but ran out of time.  Here's
the little that I discovered;  maybe someone else with
access to OS X (which I have) and an understanding of
poll (which I lack) can build on this.

The failure has to do with select.poll differences between Linux
and OS X.  It seems that OS X can return POLLIN | POLLPRI | POLLHUP
in situations where Linux just returns POLLIN, and this combination
of flags causes the code in asyncore to first close the socket and
then try to read from it.  The relevant code is at around line 440
of Lib/asyncore.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 14:15:53 2009
From: report at bugs.python.org (Loic Jaquemet)
Date: Thu, 07 May 2009 12:15:53 +0000
Subject: [issue5951] email.message : get_payload args's documentation is
	confusing
In-Reply-To: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>
Message-ID: <1241698553.12.0.793981522806.issue5951@psf.upfronthosting.co.za>


Loic Jaquemet <loic.jaquemet+python at gmail.com> added the comment:

Ok, I understand.
Thx

+ -> I need to learn python 
:/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5951>
_______________________________________

From report at bugs.python.org  Thu May  7 15:09:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 May 2009 13:09:53 +0000
Subject: [issue5951] email.message : get_payload args's documentation is
	confusing
In-Reply-To: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>
Message-ID: <1241701793.74.0.519816145364.issue5951@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No fault of yours, it's a real doc bug.  I've been programming in python
since 1997 or so, and I had to read the source code to figure it out
when I went to use get_payload a couple months ago.  That's why your bug
report caught my eye.  And even then I misremembered the answer and had
to look at the source code again to get it right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5951>
_______________________________________

From report at bugs.python.org  Thu May  7 16:23:33 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Thu, 07 May 2009 14:23:33 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241706213.28.0.0226281886426.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Hi Tarek,

there is a new patch.

  - Logger is now back to Log
  - put back INFO/DEBUG etc.
  - Wrapped the code inside a try/except 

I removed the _global_logger/logger variables, because they're
superfluous: so the cound of the module exported symbols should be 
greatly reduced (debug, info, warn, warning, error and fatal).
The warning has been put to match the Logger warning method.

I'm waiting for the suse build server to rebuild the whole python 
interpreter: the system looks very busy so I can confirm later if 
there's been any issue during the build and with the smoke tests.

----------
Added file: http://bugs.python.org/file13912/issue3992.remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu May  7 16:23:42 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Thu, 07 May 2009 14:23:42 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241706222.71.0.654312126192.issue3992@psf.upfronthosting.co.za>


Changes by Antonio Cavallo <a.cavallo at cavallinux.eu>:


Removed file: http://bugs.python.org/file13908/issue3992.remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu May  7 18:50:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 16:50:31 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241715031.05.0.359002757027.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r56632 looks relevant:

"""When running asynchat tests on OS X (darwin), the test client now
overrides asyncore.dispatcher.handle_expt to do nothing, since
select.poll gives a POLLHUP error at the completion of these tests.
Added timeout & count arguments to several asyncore.loop calls to
avoid the possibility of a test hanging up a build. [GSoC - Alan
McIntyre]"""

Adding Facundo Batista and Alan McIntyre to the nosy list.  Does either of 
you know what's going on with this issue?

----------
nosy: +alanmcintyre, facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 18:58:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 May 2009 16:58:58 +0000
Subject: [issue5955] aifc: close() does not close the underlying file
In-Reply-To: <1241690557.41.0.153347725808.issue5955@psf.upfronthosting.co.za>
Message-ID: <1241715538.06.0.976041777179.issue5955@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r72425.

----------
components: +Library (Lib)
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5955>
_______________________________________

From report at bugs.python.org  Thu May  7 19:01:34 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Thu, 07 May 2009 17:01:34 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241715694.11.0.137603881941.issue5798@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Here is a (new?) failure of test_asynchat with Python 3.1b1 on MacOS X 
10.4.11 (Intel).

% make test
....
test test_asynchat produced unexpected output:
**********************************************************************
*** lines 2-16 of actual output doesn't appear in expected output after 
line 1:
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcc30> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcb90> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcf90> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcd50> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcc30> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcb90> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcf90> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcd50> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcc30> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcb90> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dc2d0> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcc30> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcbb0> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcb90> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x21dcd50> (<class 'socket.error'
>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-3
.1b1/Lib/asyncore.py|handle_expt_event|440])
**********************************************************************
....

% ./python.exe Lib/test/test_asynchat.py
test_close_when_done (__main__.TestAsynchat) ... ok
test_empty_line (__main__.TestAsynchat) ... ok
test_line_terminator1 (__main__.TestAsynchat) ... ok
test_line_terminator2 (__main__.TestAsynchat) ... ok
test_line_terminator3 (__main__.TestAsynchat) ... ok
test_none_terminator (__main__.TestAsynchat) ... ok
test_numeric_terminator1 (__main__.TestAsynchat) ... ok
test_numeric_terminator2 (__main__.TestAsynchat) ... ok
test_simple_producer (__main__.TestAsynchat) ... ok
test_string_producer (__main__.TestAsynchat) ... ok
test_close_when_done (__main__.TestAsynchat_WithPoll) ... ok
test_empty_line (__main__.TestAsynchat_WithPoll) ... error: uncaptured 
python exception, closing channel <__main__.echo_client at 0x107cf30> 
(<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator1 (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107c3f0> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x107ceb0> (<class 'socket.error'>:[Errno 9] 
Bad file descriptor [../Python-3.1b1/Lib/asyncore.py|readwrite|106] 
[../Python-3.1b1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x107cf50> (<class 'socket.error'>:[Errno 9] 
Bad file descriptor [../Python-3.1b1/Lib/asyncore.py|readwrite|106] 
[../Python-3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator2 (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107ce70> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x107ced0> (<class 'socket.error'>:[Errno 9] 
Bad file descriptor [../Python-3.1b1/Lib/asyncore.py|readwrite|106] 
[../Python-3.1b1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x107cf30> (<class 'socket.error'>:[Errno 9] 
Bad file descriptor [../Python-3.1b1/Lib/asyncore.py|readwrite|106] 
[../Python-3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator3 (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107ceb0> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x107cf50> (<class 'socket.error'>:[Errno 9] 
Bad file descriptor [../Python-3.1b1/Lib/asyncore.py|readwrite|106] 
[../Python-3.1b1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x107cef0> (<class 'socket.error'>:[Errno 9] 
Bad file descriptor [../Python-3.1b1/Lib/asyncore.py|readwrite|106] 
[../Python-3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_none_terminator (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107cf50> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_numeric_terminator1 (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107ce10> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_numeric_terminator2 (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107ce50> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_simple_producer (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107cdb0> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_string_producer (__main__.TestAsynchat_WithPoll) ... error: 
uncaptured python exception, closing channel <__main__.echo_client at 
0x107cf50> (<class 'socket.error'>:[Errno 9] Bad file descriptor 
[../Python-3.1b1/Lib/asyncore.py|readwrite|106] [../Python-
3.1b1/Lib/asyncore.py|handle_expt_event|440])
ok
test_find_prefix_at_end (__main__.TestHelperFunctions) ... ok
test_basic (__main__.TestFifo) ... ok
test_given_list (__main__.TestFifo) ... ok

----------------------------------------------------------------------
Ran 23 tests in 7.712s

OK

----------
nosy: +MrJean1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

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: [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 19:27:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 May 2009 17:27:45 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241717265.37.0.95832921282.issue5798@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 1161031, especially Giampaolo's suggestion near the end.
 Seems like it might be relevant.  I was the one who merged Josiah's
trunk fix into othe other branches, to get things back into sync, but I
don't claim to understand the code at any deep level.  From the review I
did at my level of knowledge it seems like the change to the behavior of
when handle_expt_event is called is correct, but I was a little worried
about backward compatibility.  I now wonder if that fix should be backed
out of 2.6 and 3.0, and advertised in What's New for 2.7 and 3.1.

----------
nosy: +giampaolo.rodola, josiahcarlson, r.david.murray
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 19:35:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 17:35:26 +0000
Subject: [issue5909] Segfault in typeobject.c
In-Reply-To: <1241298853.44.0.694039818999.issue5909@psf.upfronthosting.co.za>
Message-ID: <1241717726.37.0.899001777231.issue5909@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a bug in pygobject, which has been already corrected btw:

http://git.gnome.org./cgit/pygobject/commit/?id=84706c9a73ad8b2e1dbd3eada09e4425a01d4d05

The "corrupted base object" is actually an old-style class...

[the gdb trace shows that you don't have this version: in
pyg_type_add_interfaces(), the variable 'base' was a PyTypeObject*, the
bug fix changed it to a PyObject*]

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5909>
_______________________________________

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: [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: [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:09:02 2009
From: report at bugs.python.org (Sergey Prigogin)
Date: Thu, 07 May 2009 18:09:02 +0000
Subject: [issue5952] AttributeError exception in urllib.urlopen
In-Reply-To: <1241662361.32.0.52605331473.issue5952@psf.upfronthosting.co.za>
Message-ID: <1241719742.65.0.86394606902.issue5952@psf.upfronthosting.co.za>


Sergey Prigogin <sprigogin at google.com> added the comment:

The problem is pretty obvious from the code.

URLopener.open_http contains the following code:

        if data is not None:
            h.send(data)
        errcode, errmsg, headers = h.getreply()
        fp = h.getfile()
        if errcode == 200:
            return addinfourl(fp, headers, "http:" + url)
        else:
            if data is None:
                return self.http_error(url, fp, errcode, errmsg, headers)
            else:
                return self.http_error(url, fp, errcode, errmsg,
headers, data)

In case of an error h.getfile() may return None. self.http_error (line
322) is called with None fp. http_error calls self.http_error_default
(line 339). FancyURLopener.http_error_default calls addinfourl(fp,
headers, "http:" + url) (line 579), which expects fp to be not None.

For variety of reasons I cannot run this test case with a newer Python
version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5952>
_______________________________________

From report at bugs.python.org  Thu May  7 20:24:42 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 07 May 2009 18:24:42 +0000
Subject: [issue5957] Possible mistake regarding writeback in documentation of
	shelve.open()
In-Reply-To: <1241719241.22.0.336086356581.issue5957@psf.upfronthosting.co.za>
Message-ID: <1241720682.74.0.7562818248.issue5957@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

OK, I've figured out from the comments in the example later on in the
shelf documentation what the paragraph is supposed to mean. I still
think it should be stated clearly. The distinction to be made is that
modifications to the dictionary immediately change the file contents --
d[key] = data and del d[key] are, I think, the only actions that fall
under this category -- but getting a value from the shelf then modifying
that value does NOT affect the underlying dictionary. Ever. It's not a
matter of WHEN, but WHETHER. (when writeback is False)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5957>
_______________________________________

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: [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:30:08 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 07 May 2009 18:30:08 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241721008.18.0.412210342706.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Looking at trunk, it seems like one reasonable option is to swap the 
order of handle_close() and handle_expt_event() testing and calls.  That 
would keep all reading/writing before handle_close(), which should be 
correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

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: [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: [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:51:28 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 May 2009 18:51:28 +0000
Subject: [issue5442] [3.1alpha1, 2,
	beta1] test_importlib fails on Mac OSX 10.5.6
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241722288.1.0.413348436145.issue5442@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file13622/tester.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

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: [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 20:56:46 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 May 2009 18:56:46 +0000
Subject: [issue5442] [3.1alpha1, 2,
	beta1] test_importlib fails on Mac OSX 10.5.6
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241722606.85.0.316952654983.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Bloody OS X and its default case-insensitivity.

Ismail, please try the attached patch to double-check this solves the
issue ASAP so this doesn't hold up Python 3.1 rc1.

----------
keywords: +patch
priority: low -> release blocker
stage:  -> patch review
status: open -> pending
Added file: http://bugs.python.org/file13914/case_sensitivity_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Thu May  7 21:05:19 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 07 May 2009 19:05:19 +0000
Subject: [issue5442] [3.1alpha1, 2,
	beta1] test_importlib fails on Mac OSX 10.5.6
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241723119.78.0.226820242064.issue5442@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Tested with: ./python -m test.regrtest -v test_importlib


3 failures:

======================================================================
FAIL: test_case_insensitivity 
(importlib.test.extension.test_case_sensitivity.ExtensionModuleCaseSensi
tivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/extension/test_case_sensitivity.py", line 29, 
in test_case_insensitivity
    self.assert_(hasattr(loader, 'load_module'))
AssertionError: False is not True

======================================================================
FAIL: test_lacking_parent 
(importlib.test.source.test_abc_loader.PyPycLoaderTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_abc_loader.py", line 271, in 
test_lacking_parent
    self.verify_bytecode(mock, name)
  File "/Users/cartman/Python-3.1b1/Lib/importlib/test/source/util.py", 
line 18, in wrapper
    to_return = fxn(*args, **kwargs)
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_abc_loader.py", line 253, in 
verify_bytecode
    self.assert_(name in mock.module_bytecode)
AssertionError: False is not True

======================================================================
FAIL: test_insensitive 
(importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_case_sensitivity.py", line 49, in 
test_insensitive
    self.assert_(hasattr(insensitive, 'load_module'))
AssertionError: False is not True

----------------------------------------------------------------------
Ran 166 tests in 0.133s

FAILED (failures=3)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Thu May  7 21:10:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 19:10:10 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241723410.99.0.392829501008.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Josiah, that solution isn't working for me;  it looks as though there's 
a deeper weirdness:  what I'm seeing is that on OS X, in e.g. 
test_emptyline, we end up calling the readwrite function in asyncore.py 
with flags = POLLIN | POLLPRI | POLLHUP.  The first thing that gets 
called is obj.handle.read_event, and bizarrely it seems to be the 
read_event call that has the effect of closing the socket.  So the 
socket's already closed by the time we get to obj.handle_expt_event and 
the same error as before occurs.

I'm still trying to figure out why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 21:28:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 19:28:07 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241724487.98.0.0573518290646.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So the sequence of events seems to be:
  asyncore.readwrite calls obj.handle_read_event
  ... which calls obj.handle_read (3rd branch of handle_read_event)
  ... which is defined in asynchat.py;  it calls obj.recv
  ... (back in asyncore now): recv calls obj.socket.recv
  ... and gets no data, so it then calls obj.handle_close
  ... which calls obj.close(), and so closes obj.socket as well.

and now obj.handle_expt_event gets confused because the socket is 
closed.

Now what?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

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: [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  Thu May  7 21:33:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 19:33:02 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241724782.99.0.119069477981.issue5963@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This may be a format error rather than a doc error.  Eric?

----------
nosy: +eric.smith, marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Thu May  7 21:34:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 19:34:56 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241724896.25.0.209877814837.issue5963@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry;  ignore me.  I should have read more carefully, and paid
attention to what was going on on python-dev as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Thu May  7 21:35:11 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 May 2009 19:35:11 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241724911.45.0.752691395395.issue5963@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

PEP 3101 says it's ignored. I chose to be strict. I don't see the
advantage of allowing but ignoring it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Thu May  7 21:35:45 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 May 2009 19:35:45 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241724945.26.0.765910347893.issue5963@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee: georg.brandl -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Thu May  7 21:40:20 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 May 2009 19:40:20 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241725220.46.0.510176660936.issue5963@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I updated the docs to say precision is not allowed for integers.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Thu May  7 21:50:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 07 May 2009 19:50:54 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241725854.93.0.180588273875.issue5753@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

re: gedit

"""I'm by no means an expert (I did not design the original python module 
extension), we simply copied from vim at the beginning. That said, it 
seems there are issues if you embed the python interpreter and do not 
explicitly set sys.argv to something.""" - jesse

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu May  7 21:52:45 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 07 May 2009 19:52:45 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241725965.97.0.854918386765.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

It would seem that we need to be more defensive in our calls.  We need 
to check to make sure that the socket isn't closed before calling 
read/write/expt events.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 22:02:41 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 May 2009 20:02:41 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241726561.67.0.288372149722.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Damn, that patch should have caused those case-sensitivity tests to be
skipped. I will dig into this later today and hopefully have another
patch to test some time tonight.

----------
resolution: fixed -> 
title: [3.1alpha1,2,beta1] test_importlib fails on Mac OSX 10.5.6 -> test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive file system

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Thu May  7 22:03:03 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 07 May 2009 20:03:03 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241726583.51.0.645625726051.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Mark, try this:

        if flags & select.POLLIN and (obj.connected or obj.accepting):
            obj.handle_read_event()
        if flags & select.POLLOUT and obj.connected:
            obj.handle_write_event()
        if flags & select.POLLPRI and obj.connected:
            obj.handle_expt_event()
        if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL):
            obj.handle_close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 22:10:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 20:10:53 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241727053.75.0.552352542435.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That fixes test_empty_line (in test_asynchat.py), but now I get a hang in 
test_close_when_done.

By the way, here's an interesting site that goes some way to explaining 
what to expect from select.poll and EOF.

http://www.greenend.org.uk/rjk/2001/06/poll.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 22:15:03 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 07 May 2009 20:15:03 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241727303.53.0.22778875206.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Try getting rid of the "and" clause in the select.POLLIN .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 22:18:06 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 07 May 2009 20:18:06 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241727486.86.0.0995825538309.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

To be clear, make the first test read...
        if flags & select.POLLIN:
            obj.handle_read_event()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 22:30:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 May 2009 20:30:16 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241728216.45.0.635093016648.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Getting rid of the and ... on the handle_read_event didn't make a 
difference:  I still get the hang in test_close_when_done.

But if I get rid of the and clause on the handle_write_event branch then
all the test_asynchat tests pass.  So that block now looks like:

        if flags & select.POLLIN and (obj.connected or obj.accepting):
            obj.handle_read_event()
        if flags & select.POLLOUT:
            obj.handle_write_event()
        if flags & select.POLLPRI and obj.connected:
            obj.handle_expt_event()
        if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL):
            obj.handle_close()

in my code.  So we're making progress (maybe). Unfortunately, 
test_asyncore now fails with:

======================================================================
FAIL: test_readwrite (__main__.HelperFunctionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_asyncore.py", line 161, in test_readwrite
    self.assertEqual(getattr(tobj, attr), attr==expectedattr)
AssertionError: False != True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Thu May  7 22:34:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 20:34:58 +0000
Subject: [issue5952] AttributeError exception in urllib.urlopen
In-Reply-To: <1241662361.32.0.52605331473.issue5952@psf.upfronthosting.co.za>
Message-ID: <1241728498.62.0.544337007553.issue5952@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the info.
This problem is a duplicate of issue767111, which was corrected two 
years ago.
I suggest you to upgrade to 2.5 at least.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5952>
_______________________________________

From report at bugs.python.org  Thu May  7 23:20:07 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 07 May 2009 21:20:07 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241731207.51.0.123506871002.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I went ahead and plugged my mac in (which reminded me of why I unplugged 
it in the first place), and I'm able to reproduce your error in the test 
after my proposed modifications.

One thing to remember is that the test is broken; we rely on a 
.connected attribute, which the test objects lack.

The attached patch fixes the test on my OS X machine, which you should 
test.

----------
keywords: +patch
Added file: http://bugs.python.org/file13915/asyncore_fix_mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May  7 23:30:21 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: Thu, 07 May 2009 21:30:21 +0000
Subject: [issue5941] customize_compiler broken
In-Reply-To: <1241514562.72.0.325228303224.issue5941@psf.upfronthosting.co.za>
Message-ID: <1241731821.59.0.185861725476.issue5941@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in r72445 and r72446

Thanks David !

----------
status: open -> closed
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5941>
_______________________________________

From report at bugs.python.org  Thu May  7 23:31:27 2009
From: report at bugs.python.org (Kevin Watters)
Date: Thu, 07 May 2009 21:31:27 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1241731887.31.0.370562044132.issue5949@psf.upfronthosting.co.za>


Kevin Watters <kevinwatters at gmail.com> added the comment:

I wasn't sure--the docs for SSLSocket.read 
(http://docs.python.org/library/ssl.html#ssl.SSLSocket.read) say

  "Reads up to nbytes bytes from the SSL-encrypted channel and returns 
them."

With that "up to" I wasn't sure that an empty string would necessarily 
mean EOF--I'm not familiar enough with _ssl.c to say either way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May  7 23:34:23 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: Thu, 07 May 2009 21:34:23 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241732063.95.0.940927625918.issue3992@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file11650/remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May  7 23:34:27 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: Thu, 07 May 2009 21:34:27 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241732067.67.0.319739038262.issue3992@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file13260/remove-custom-log-revised.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Fri May  8 01:21:32 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: Thu, 07 May 2009 23:21:32 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241738492.35.0.0470451170652.issue3992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> I removed the _global_logger/logger variables, because they're
> superfluous

Yes but by adding "log" instead, and removing "log = _global_log.log"
you are breaking Distutils because its uses "log.log"

Besides, the rest seem OK.

I'll work on your patch, and add a few tests with it and let you know
when it's up, thanks !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Fri May  8 01:28:03 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 23:28:03 +0000
Subject: [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: <1241738883.22.0.790568229414.issue5924@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

After some attempts, it seems that PYTHONPATH is completely ignored if 
it is longer than 256 characters

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Fri May  8 01:39:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 May 2009 23:39:37 +0000
Subject: [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: <1241739577.46.0.37217519858.issue5924@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Confirmed in PC/getpathp.c:
		size_t r = mbstowcs(wenvpath, _envpath, MAXPATHLEN+1);
		envpath = wenvpath;
		if (r == (size_t)-1 || r >= MAXPATHLEN)
			envpath = NULL;

----------
nosy: +loewis
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Fri May  8 01:58:15 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 May 2009 23:58:15 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241740695.8.0.566782617451.issue5442@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file13914/case_sensitivity_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Fri May  8 02:00:16 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 May 2009 00:00:16 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241740816.32.0.088147585645.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, Ismail, here is another patch. Revert the last one and try this.
Looks like I was being stupid by forgetting to remove the 'darwin'
platform check. But I also made the check simpler.

----------
status: open -> pending
Added file: http://bugs.python.org/file13916/case_sensitivity_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Fri May  8 02:05:41 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: Fri, 08 May 2009 00:05:41 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241741141.76.0.224553428883.issue3992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have reworked your patch a little bit so it works for Distutils. But I
still need to digg on the initialization problem to see if we can get
rid of the problem  : the new logging will not get imported as well
during tests so it is not what we want yet

----------
Added file: http://bugs.python.org/file13917/custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Fri May  8 02:11:38 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 08 May 2009 00:11:38 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241741498.09.0.215924764208.issue5798@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

I reran the test_synchat.py test after patching to the Lib/asyncore.py 
and Lib/test/test-asynchat.py files of Python-3.1b1 on MacOS X 10.4.11 
(Intel).

The test now hangs in
...
test_string_producer (__main__.TestAsynchat) ... ok
test_close_when_done (__main__.TestAsynchat_WithPoll) ...

The test also hangs, after removing the patches from the 
Lib/test/test_asynchat.py file but keeping the patched Lib/asyncore.py 
file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 02:18:46 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 May 2009 00:18:46 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241741926.74.0.27510236972.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

As an aside, I was testing against trunk, not 3.1b1 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Fri May  8 02:19:26 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: Fri, 08 May 2009 00:19:26 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241741966.47.0.421650419826.issue3992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok the problem occurs because site.py calls distutils.util.get_platform
in addbuilddir. I'll see what we can do in there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Fri May  8 02:40:32 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 08 May 2009 00:40:32 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1241741926.74.0.27510236972.issue5798@psf.upfronthosting.co.za>
Message-ID: <39a48f50905071740v424cccf9p3a7fc675ee7af94d@mail.gmail.com>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Understood.

On Thu, May 7, 2009 at 5:18 PM, Josiah Carlson <report at bugs.python.org>wrote:

>
> Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:
>
> As an aside, I was testing against trunk, not 3.1b1 .
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5798>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file13918/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________
-------------- next part --------------
Understood.<div><br><div><br><div class="gmail_quote">On Thu, May 7, 2009 at 5:18 PM, Josiah Carlson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Josiah Carlson &lt;<a href="mailto:josiahcarlson at users.sourceforge.net">josiahcarlson at users.sourceforge.net</a>&gt; added the comment:<br>
<br>
</div>As an aside, I was testing against trunk, not 3.1b1 .<br>
<div><div></div><div class="h5"><br>
----------<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue5798" target="_blank">http://bugs.python.org/issue5798</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div>

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: [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: [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 03:35:34 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 May 2009 01:35:34 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1241746534.04.0.546168785408.issue5965@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I forgot to include:

Error messages for mismatches between specification type and value type
currently look like

"ValueError: Unknown conversion type d"

They would be *much* clearer written as something like

"ValueError: Conversion type d is invalid for float values"

and similarly for similar errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

From report at bugs.python.org  Fri May  8 03:37:39 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 May 2009 01:37:39 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241746659.03.0.695063574208.issue5963@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whoops, I believe my suggested replacement.
"A precision is not allowed for integer values."
should really be
"A precision is not allowed for integer presentation types."
or something similar.

If you did not change the end of the sentence, please do.  A precision 
*is* allowed for integer values (integers) if a float presentation type
is used, because they are auto-converted (though floats are not).

This is not documented but I think it should be.  See #5965 for this and
related suggestions.

For future reference, in case anyone ever objects, I agree with
remaining strict and changing the doc.
1) Given that the code is strict about the other 'only valid'
restrictions (I checked some and it seems to be), it seems reasonable to
be consistency strict with precision and ints also.
2) Given that there are 7 presentation types for int and 8 for floats,
it is easily possible to make an error.  Best to catch it early.

The only possible use case I can think of for precision with ints is
something like
'{0:10.3{1}}'.format(val, typ) # fails for int typs

but we fail-proof that, we should also fail-proof '#' with floats:
'{0:#10{1}}'.format(val, typ)# fails for float typs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Fri May  8 03:55:21 2009
From: report at bugs.python.org (Suzumizaki)
Date: Fri, 08 May 2009 01:55:21 +0000
Subject: [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: <1241747721.74.0.998226934835.issue5924@psf.upfronthosting.co.za>


Changes by Suzumizaki <suzumizaki at free.japandesign.ne.jp>:


----------
nosy: +Suzumizaki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Fri May  8 05:59:53 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 08 May 2009 03:59:53 +0000
Subject: [issue4351] [PATCH] Better stacklevel for GzipFile.filename
	DeprecationWarning
In-Reply-To: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za>
Message-ID: <1241755193.44.0.588600503908.issue4351@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

this and more applied in r72458

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4351>
_______________________________________

From report at bugs.python.org  Fri May  8 07:07:15 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 08 May 2009 05:07:15 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241759234.94.0.106371899822.issue5442@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Down to 1 failure:

FAILED (failures=1)
test test_importlib failed -- Traceback (most recent call last):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_abc_loader.py", line 271, in 
test_lacking_parent
    self.verify_bytecode(mock, name)
  File "/Users/cartman/Python-3.1b1/Lib/importlib/test/source/util.py", 
line 18, in wrapper
    to_return = fxn(*args, **kwargs)
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_abc_loader.py", line 253, in 
verify_bytecode
    self.assertIn(name, mock.module_bytecode)
AssertionError: 'pkg.mod' not found in {}

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Fri May  8 07:57:21 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 May 2009 05:57:21 +0000
Subject: [issue5809] "No such file or directory" with framework build under
	MacOS 10.4.11
In-Reply-To: <1240329712.27.0.0341104214309.issue5809@psf.upfronthosting.co.za>
Message-ID: <1241762241.38.0.306595743127.issue5809@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

--enable-framework and --enable-shared are mutually exclusive options.  
See, for example, the discussion in Issue4472.  Use one or the other, not 
both.

As a side comment, I think this error crops up often enough that it would 
make sense to add a check somewhere (configure?) and produce a useful 
error.

----------
nosy: +nad, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5809>
_______________________________________

From report at bugs.python.org  Fri May  8 08:31:30 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 May 2009 06:31:30 +0000
Subject: [issue4432] IDLE.app (Mac) File Menu MIssing Options
In-Reply-To: <1227662544.21.0.925756353896.issue4432@psf.upfronthosting.co.za>
Message-ID: <1241764289.7.0.357102109625.issue4432@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Can not reproduce with 3.0.1.  A number of fixes were checked in for OS X 
Python builds and specifically for IDLE menus between 3.0rc3 and 3.0.1.  
See, for example, Issue5196 and Issue5194.

----------
nosy: +nad, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4432>
_______________________________________

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: [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 10:22:29 2009
From: report at bugs.python.org (Tomalak)
Date: Fri, 08 May 2009 08:22:29 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241770949.89.0.610773496435.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Hmm... I thought toxml() is the part that needs to be fixed, not the
parsing/reading. I mentioned the reading only to outline the data loss
that occurs eventually.

My point is: The toxml() (i.e. _write_data) *actually writes* the
newline to the output. And within parameters, it just shouldn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Fri May  8 11:02:26 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 08 May 2009 09:02:26 +0000
Subject: [issue5963] Doc error: integer precision in formats
In-Reply-To: <1241724711.12.0.650660352068.issue5963@psf.upfronthosting.co.za>
Message-ID: <1241773346.49.0.741301308664.issue5963@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

"integer presentation types" is still not exactly correct, because there
are presentation types that work across value types. Specifically, 'n'
works on integers and floats. Precision is allowed for floats, but not ints:

>>> format(10.0, '.4n')
'10'
>>> format(10, '.4n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Precision not allowed in integer format specifier

Without getting into all sorts of language lawyering, I think it's good
enough as-is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5963>
_______________________________________

From report at bugs.python.org  Fri May  8 11:33:30 2009
From: report at bugs.python.org (Tomalak)
Date: Fri, 08 May 2009 09:33:30 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241775210.75.0.0474972105524.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Attaching a patch that fixes the problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file13919/minidom.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Fri May  8 11:38:11 2009
From: report at bugs.python.org (Tomalak)
Date: Fri, 08 May 2009 09:38:11 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241775491.64.0.345633056493.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Attaching a test file that outlines the problem. Output on my system
(Windows / Python 3.0) is:

Without the patch:
C:\Python30>python.exe c:\minidom_test.py
False
1 -->"multiline
value"
2 -->"multiline value"

With the patch:
C:\Python30>python.exe c:\minidom_test.py
True
1 -->"multiline
value"
2 -->"multiline
value"

----------
Added file: http://bugs.python.org/file13920/toxml_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Fri May  8 11:52:50 2009
From: report at bugs.python.org (Tomalak)
Date: Fri, 08 May 2009 09:52:50 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241776370.08.0.66753050764.issue5752@psf.upfronthosting.co.za>


Changes by Tomalak <M8R-t1tut01 at mailinator.com>:


Removed file: http://bugs.python.org/file13920/toxml_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Fri May  8 11:53:34 2009
From: report at bugs.python.org (Tomalak)
Date: Fri, 08 May 2009 09:53:34 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241776414.43.0.357761096483.issue5752@psf.upfronthosting.co.za>


Changes by Tomalak <M8R-t1tut01 at mailinator.com>:


Added file: http://bugs.python.org/file13921/minidom_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Fri May  8 12:23:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 May 2009 10:23:43 +0000
Subject: [issue5959] PyCode_NewEmpty
In-Reply-To: <1241720694.59.0.328707962514.issue5959@psf.upfronthosting.co.za>
Message-ID: <1241778223.71.0.882186608774.issue5959@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good idea. The patch lacks some documentation.

----------
nosy: +pitrou
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5959>
_______________________________________

From report at bugs.python.org  Fri May  8 12:25:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 May 2009 10:25:01 +0000
Subject: [issue5959] PyCode_NewEmpty
In-Reply-To: <1241720694.59.0.328707962514.issue5959@psf.upfronthosting.co.za>
Message-ID: <1241778301.89.0.0264535755842.issue5959@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jyasskin
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5959>
_______________________________________

From report at bugs.python.org  Fri May  8 12:29:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 May 2009 10:29:30 +0000
Subject: [issue5954] PyFrame_GetLineNumber
In-Reply-To: <1241679764.04.0.154044942183.issue5954@psf.upfronthosting.co.za>
Message-ID: <1241778570.18.0.394293797647.issue5954@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please add doc to the patch, it looks ok otherwise.

----------
assignee:  -> jyasskin
nosy: +pitrou
resolution:  -> accepted
stage: patch review -> commit review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5954>
_______________________________________

From report at bugs.python.org  Fri May  8 13:17:16 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 08 May 2009 11:17:16 +0000
Subject: [issue2178] Problems with Belarusian Latin locale
In-Reply-To: <1203887565.7.0.326406718733.issue2178@psf.upfronthosting.co.za>
Message-ID: <1241781436.79.0.911538620336.issue2178@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Interesting. I'll see if I can dig into this.

----------
nosy: +asmodai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2178>
_______________________________________

From report at bugs.python.org  Fri May  8 13:28:28 2009
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 08 May 2009 11:28:28 +0000
Subject: [issue4787] Curses Unicode Support
In-Reply-To: <1230677862.93.0.319255171122.issue4787@psf.upfronthosting.co.za>
Message-ID: <1241782108.37.0.118404137677.issue4787@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

On FreeBSD there's no need for the ncurses package in most case. Since
somewhere along 6.x and 7.x line Rong-En Fan switched FreeBSD to do what
I did for DragonFly BSD a long time: to have both normal and wide curses
available.

As far as Python is concerned, it supports linking to ncursesw, so I
think this issue can be safely closed since it is not a problem within
Python (as also the original author said).

If this is not ok, feel free to reopen.

----------
nosy: +asmodai
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4787>
_______________________________________

From report at bugs.python.org  Fri May  8 14:14:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 May 2009 12:14:58 +0000
Subject: [issue5955] aifc: close() does not close the underlying file
In-Reply-To: <1241690557.41.0.153347725808.issue5955@psf.upfronthosting.co.za>
Message-ID: <1241784898.33.0.289896672773.issue5955@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5955>
_______________________________________

From report at bugs.python.org  Fri May  8 14:16:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 May 2009 12:16:16 +0000
Subject: [issue5958] Typo in documentation of shelve.sync
In-Reply-To: <1241719305.68.0.372814278118.issue5958@psf.upfronthosting.co.za>
Message-ID: <1241784976.81.0.647479581313.issue5958@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's not a bug -- what is documented there is a method of the Shelf
classes.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5958>
_______________________________________

From report at bugs.python.org  Fri May  8 14:18:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 May 2009 12:18:14 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1241785094.41.0.26478398894.issue5965@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

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: [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 14:55:55 2009
From: report at bugs.python.org (Retro)
Date: Fri, 08 May 2009 12:55:55 +0000
Subject: [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: <1241787355.28.0.636830038543.issue5967@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

You have mispelled a word in the patch. The sentence should be  Negative
indices not supported.

Please make another patch without the "indicies" typo.

----------
nosy: +Retro

_______________________________________
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: [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 15:48:34 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 08 May 2009 13:48:34 +0000
Subject: [issue5958] Typo in documentation of shelve.sync
In-Reply-To: <1241784976.81.0.647479581313.issue5958@psf.upfronthosting.co.za>
Message-ID: <p06240810c629e481ce87@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

Sorry. Careless again.
-- 
-- 

         --- Mitchell

----------
Added file: http://bugs.python.org/file13924/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5958>
_______________________________________
-------------- next part --------------
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [issue5958] Typo in documentation of
shelve.sync</title></head><body>
<div>Sorry. Careless again.</div>
<div><tt>-- </tt></div>

<div>-- <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --- Mitchell</div>
</body>
</html>

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: [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 16:10:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 May 2009 14:10:20 +0000
Subject: [issue5968] Generator expression bug?
In-Reply-To: <1241789090.54.0.0922796192042.issue5968@psf.upfronthosting.co.za>
Message-ID: <1241791820.49.0.420788047999.issue5968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is not a bug.  It's not even a doc bug, IMO.

When you do

  num1 = [x for x in range(0, 6)]

it is not that you are assigning a list comprehension to num1, what you
are doing is running a list comprehension to create an actual list,
which is what gets assigned to num1.  The docs are pretty clear about
that, I think.  So yes you can iterate over a list multiple times,
because of how it implements the iteration protocol. 

On the other hand, when you do

  num3 = (x for x in range(0, 6))

you create a generator object, which is what gets assigned to num3. 
Generators created by generator expressions can only be iterated over
until they are exhausted.  That is a major point of their existence:
producing one item at a time on demand and not saving them.

A range object is its own special case, and is neither a list nor a
generator.  It is reusable, as you found.

None of this should be documented in the 'for' statement.  The for
statement explains the protocol it follows.  What happens when you use
it to iterate over any given object depends on how that object
impelements the iteration protcol.  So you have to look to the
documentation of those objects for further enlightenment, I'm afraid.

----------
nosy: +r.david.murray
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5968>
_______________________________________

From report at bugs.python.org  Fri May  8 17:15:02 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 08 May 2009 15:15:02 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241795702.19.0.259455726589.issue5798@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Has anyone already tried to modify readwrite() as I was suggesting here?
http://bugs.python.org/issue1161031#msg84892

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 17:22:29 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 08 May 2009 15:22:29 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1241796149.85.0.289233786532.issue5965@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'll look at it. The comma stuff needs to be added for 2.7 and 3.1, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

From report at bugs.python.org  Fri May  8 17:32:16 2009
From: report at bugs.python.org (Mihai Ibanescu)
Date: Fri, 08 May 2009 15:32:16 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1241796736.3.0.017113827347.issue1298813@psf.upfronthosting.co.za>


Mihai Ibanescu <mihai.ibanescu at gmail.com> added the comment:

Disclaimer: this bug is more than 3 years old, I don't remember all the
details.

Victor, solely reading the patch I see:

+#ifdef HAVE_CANONICALIZE_FILE_NAME
+		free(argv0);
+#endif /* HAVE_CANONICALIZE_FILE_NAME */

so argv0 (the string where the results of canonicalize_file_name() is
stored) should be freed.

Is there another branch that does not hit this code, that would create
the memory leak?

----------
nosy: +mibanescu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298813>
_______________________________________

From report at bugs.python.org  Fri May  8 18:10:28 2009
From: report at bugs.python.org (fanda.vacek)
Date: Fri, 08 May 2009 16:10:28 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1241799028.35.0.688139232948.issue4066@psf.upfronthosting.co.za>


Changes by fanda.vacek <fanda.vacek at volny.cz>:


----------
nosy: +fanda.vacek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Fri May  8 18:18:48 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 08 May 2009 16:18:48 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241799528.09.0.00138242138323.issue5798@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Indeed, the unmodified test_asynchat.py now passes in Python 3.1b1.  The 
readwrite function in asyncore looks like this now:

def readwrite(obj, flags):
    try:
        if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL):
            obj.handle_close()
        else:
            if flags & select.POLLIN:
                obj.handle_read_event()
            if flags & select.POLLOUT:  # and obj.connected:
                obj.handle_write_event()
            if flags & select.POLLPRI:  # and obj.connected:
                obj.handle_expt_event()
    except _reraised_exceptions:
        raise
    except:
        obj.handle_error()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 18:33:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 May 2009 16:33:27 +0000
Subject: [issue5918] test_parser crashes when run after some other tests
In-Reply-To: <1241395274.73.0.21825310934.issue5918@psf.upfronthosting.co.za>
Message-ID: <1241800407.65.0.579794504418.issue5918@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Great! The patch seems to fix it (although it's difficult to say for
sure since the crashes were intermittent). I apologize for incriminating
distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5918>
_______________________________________

From report at bugs.python.org  Fri May  8 18:47:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 May 2009 16:47:28 +0000
Subject: [issue5957] Possible mistake regarding writeback in documentation of
	shelve.open()
In-Reply-To: <1241719241.22.0.336086356581.issue5957@psf.upfronthosting.co.za>
Message-ID: <1241801248.73.0.799502578917.issue5957@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I remember being confused by that paragraph.  Attached is a suggested
doc fix.  Do you think it makes it clear enough?  (I'm not happy with
the redundancy of saying mutation can't be detected twice in the same
paragraph, but it seems better to be redundant than unclear.)

----------
assignee: georg.brandl -> r.david.murray
keywords: +patch
nosy: +r.david.murray
priority:  -> low
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6, Python 2.7
Added file: http://bugs.python.org/file13925/issue5957.doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5957>
_______________________________________

From report at bugs.python.org  Fri May  8 18:58:58 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 May 2009 16:58:58 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241801938.84.0.496709603703.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the quick reply, Ismail! I will look into the last failure
this weekend, but off the top of my head I am not sure why that test
would be failing since everything to do with that test should be a mock
and thus not touching the file system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Fri May  8 19:18:52 2009
From: report at bugs.python.org (Sven Rahmann)
Date: Fri, 08 May 2009 17:18:52 +0000
Subject: [issue5968] Generator expression bug?
In-Reply-To: <1241789090.54.0.0922796192042.issue5968@psf.upfronthosting.co.za>
Message-ID: <1241803132.9.0.851190482969.issue5968@psf.upfronthosting.co.za>


Sven Rahmann <svenrahmann at googlemail.com> added the comment:

I complete agree that by
x = (z for z in y)
I create and assign a generator object to x.


I'm afraid I disagree about "not a doc bug".
The documentation for "for" reads:

===
for_stmt ::=  "for" target_list "in" expression_list ":" suite
              ["else" ":" suite]

The expression list is evaluated once; it should yield an iterable
object. An iterator is created for the result of the expression_list.
===
(http://docs.python.org/3.0/reference/compound_stmts.html#the-for-statement)

This ("an iterator is created") suggests that a new iterator is created
for the generator object (the iterable).

I was actually surprised to find that the __iter__() function of a
generator object returns the generator object itself. 


If generator objects behave as they do, I'm probably going to file a
feature request for something like "reusable" generators.

In fact, with the attached file I'm trying to extract a column from a
matrix and use it for several computations. Since I don't want to copy
the values of a column (imagine a huge matrix), I want to create a
reusable generator object that repeatedly returns a generator object
that enumerates the values of a single column.

My impression was that generator expressions are useful for just this
type of application.

Therefore, the attached file now as a small class ReusableGenerator that
implements this behavior. However, the "ugly" part is that in order to
create it, you have to pass it a function that returns a generator
object, not the generator object itself.

Another attempt by deep-copying completely fails, and I don't understand
why this is the case; probably there's a good reason.

----------
status: closed -> open
Added file: http://bugs.python.org/file13926/generatorbug3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5968>
_______________________________________

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: [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 19:49:32 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 May 2009 17:49:32 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241804972.37.0.348125739072.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

One of the issues with using the method that Giampaolo describes, which 
I explained to him, is that generally if someone sends you data, you 
want to receive it.  You can get both data and the signal that someone 
disconnected, in particular, with asynchat's .close_when_done() method.

If you get a read signal, generally you want to try to pull more data 
before you close, because when you close, you can never get any pending 
data again.

For example, if I were to use:
  chat.send("commit\n")
  chat.close_when_done()
It's very likely that on even moderate latency network connections 
(10ms), the other end would get the close signal at the same time as the 
read for the "commit\n" message.  But since they close before they read, 
they never get the "commit" message, and maybe a transaction is 
reverted.

My primary concern is keeping the library correct.  Adding attributes in 
the test cases don't bother me.

Jean: on what platform are you experiencing the hang?  Are you using 
trunk or 3.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 19:49:56 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 08 May 2009 17:49:56 +0000
Subject: [issue5970] sys.exc_info leaks into a generator
In-Reply-To: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>
Message-ID: <1241804996.2.0.792653596513.issue5970@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I think we should _not_ backport any fix for this bug to the 2.6 series,
since any changes to user behavior would be pretty subtle. To prevent
that backport, I'd like to apply exc_info_26.patch to the 2.6 branch,
with Barry's approval.

----------
assignee:  -> barry
nosy: +barry
Added file: http://bugs.python.org/file13928/exc_info_26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5970>
_______________________________________

From report at bugs.python.org  Fri May  8 20:24:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 May 2009 18:24:09 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241807049.49.0.232294358749.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With Josiah's patch, on trunk (r72475), test_asyncore passes, but
test_asynchat is still hanging in the test:

test_close_when_done (__main__.TestAsynchat_WithPoll) ... 

The hang occurs at the line "data = conn.recv(1)" in the run method
of the echo_server class in Lib/test/test_asynchat.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 20:27:41 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 08 May 2009 18:27:41 +0000
Subject: [issue5957] Possible mistake regarding writeback in documentation of
	shelve.open()
In-Reply-To: <1241801248.73.0.799502578917.issue5957@psf.upfronthosting.co.za>
Message-ID: <p06240815c62a2408b216@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

>http://bugs.python.org/file13925/issue5957.doc.patch

I just spent some time attempting a rewrite, and while I liked what I 
ended up with it wasn't all that different from the patch. I'm happy 
with the patch.
-- 
-- 

         --- Mitchell

----------
title: Possible mistake regarding writeback in documentation of shelve.open() -> Possible mistake regarding writeback in documentation of 	shelve.open()
Added file: http://bugs.python.org/file13929/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5957>
_______________________________________
-------------- next part --------------
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [issue5957] Possible mistake regarding
writeback in do</title></head><body>
<blockquote type="cite"
cite>http://bugs.python.org/file13925/issue5957.doc.patch</blockquote>
<div><br></div>
<div>I just spent some time attempting a rewrite, and while I liked
what I ended up with it wasn't all that different from the patch. I'm
happy with the patch.</div>
<div><tt>-- </tt></div>

<div>-- <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --- Mitchell</div>
</body>
</html>

From report at bugs.python.org  Fri May  8 20:41:47 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 May 2009 18:41:47 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1241808107.47.0.0250070102608.issue5953@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Alternatively, range objects could have a .__eq__ method that compares
the (hidden) start, stop, and step attributes used to print the
representations.

As a workaround, str(r1)==str(rs) will work as expected.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From report at bugs.python.org  Fri May  8 20:53:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 May 2009 18:53:37 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241808817.71.0.634048945939.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With Giampaolo's suggested change, all tests pass.  My understanding of 
what asyncore/asynchat is intended to do and how it might be used in 
practice is weak, so I don't feel qualified to comment on the 
correctness of the change.

> One of the issues with using the method that Giampaolo describes, 
which 
> I explained to him, is that generally if someone sends you data, you 
> want to receive it.  You can get both data and the signal that someone 
> disconnected, in particular, with asynchat's .close_when_done() 
method.

Is it possible to add a test for this sort of situation, to make sure 
that future changes take it into account?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 20:56:25 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 08 May 2009 18:56:25 +0000
Subject: [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: <1241808985.89.0.541396567176.issue5895@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Naoyuki,
Is the API a mix of size_t and int? Does the attached patch help?

If you could confirm that building with _XOPEN_SOURCE_EXTENDED doesn't
need a change, the #ifdef should check for that too.

----------
components: +Build
keywords: +patch
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.5, Python 3.0
Added file: http://bugs.python.org/file13930/hpux_socklen_t_int.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5895>
_______________________________________

From report at bugs.python.org  Fri May  8 21:08:11 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 08 May 2009 19:08:11 +0000
Subject: [issue5911] built-in compile() should take encoding option.
In-Reply-To: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>
Message-ID: <1241809691.38.0.191177756439.issue5911@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Interpreter Core, Unicode -None
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5911>
_______________________________________

From report at bugs.python.org  Fri May  8 21:08:41 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 08 May 2009 19:08:41 +0000
Subject: [issue1542677] compile(): IDLE shell gives different len() of unicode
	strings compared to Python shell
Message-ID: <1241809721.25.0.888814842579.issue1542677@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +built-in compile() should take encoding option.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542677>
_______________________________________

From report at bugs.python.org  Fri May  8 21:11:36 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 May 2009 19:11:36 +0000
Subject: [issue5968] Generator expression bug?
In-Reply-To: <1241789090.54.0.0922796192042.issue5968@psf.upfronthosting.co.za>
Message-ID: <1241809896.66.0.478400858683.issue5968@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Questions and discussions like this should be directed to the
python-list, mirrored on newsgroups comp.lang.python and
gmane.comp.python.general (or possibly other forums).

I will say this much but *only* this much here:
1. Generators are iterators; by definition, iterator.__init__ returns
itself.  Nearly all iterators are single use.
2. Generator functions and their abbreviated form, generator
expressions, create generators.  To re-iterate, re-call the generator
function or re-execute the generator expression.

It is possible that discussion elsewhere would generator specific doc
improvement suggestions that could be submitted in a new issue.

----------
nosy: +tjreedy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5968>
_______________________________________

From report at bugs.python.org  Fri May  8 21:13:13 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Fri, 08 May 2009 19:13:13 +0000
Subject: [issue5809] "No such file or directory" with framework build under
	MacOS 10.4.11
In-Reply-To: <1240329712.27.0.0341104214309.issue5809@psf.upfronthosting.co.za>
Message-ID: <1241809993.97.0.636000636953.issue5809@psf.upfronthosting.co.za>


Michael J. Fromberger <michael.j.fromberger at gmail.com> added the comment:

Ned Deily writes:
> --enable-framework and --enable-shared are mutually exclusive options. 

Aha, I did not realize that, though I suppose in retrospect it should have 
been obvious.  Removing "--enable-shared" from my build configuration does 
enable me to build with "--enable-framework" selected.

I agree that this should be either better documented, or checked for by 
the configurator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5809>
_______________________________________

From report at bugs.python.org  Fri May  8 21:14:10 2009
From: report at bugs.python.org (Eric Woudenberg)
Date: Fri, 08 May 2009 19:14:10 +0000
Subject: [issue1483545] Wave.py support for ulaw and alaw audio
Message-ID: <1241810050.87.0.447546443249.issue1483545@psf.upfronthosting.co.za>


Eric Woudenberg <ewoudenberg at users.sourceforge.net> added the comment:

Patch applied to Python 2.4 wave.py

----------
Added file: http://bugs.python.org/file13931/wave24.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483545>
_______________________________________

From report at bugs.python.org  Fri May  8 21:14:49 2009
From: report at bugs.python.org (Eric Woudenberg)
Date: Fri, 08 May 2009 19:14:49 +0000
Subject: [issue1483545] Wave.py support for ulaw and alaw audio
Message-ID: <1241810089.0.0.536724166582.issue1483545@psf.upfronthosting.co.za>


Eric Woudenberg <ewoudenberg at users.sourceforge.net> added the comment:

Patch applied to Python 2.5 wave.py

----------
Added file: http://bugs.python.org/file13932/wave25.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483545>
_______________________________________

From report at bugs.python.org  Fri May  8 21:34:28 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 08 May 2009 19:34:28 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241808107.47.0.0250070102608.issue5953@psf.upfronthosting.co.za>
Message-ID: <p0624081ac62a35eae2f6@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

Yes, that's why I was surprised. It's rare (isn't it?) to have str(a) 
== str(b) but a != b.  a not is b, sure, but a != b? Note also that 
list(range(n)) == list(range(n)). If the lists are equal and the 
strings are equal it's hard to see why the objects wouldn't be equal.

There are other things like range that define equality; for instance
	date.today() == datetime.date(2009, 5, 8)
Seems like ranges should define equals too.

However, I do understand the technical argument for saying not to use 
ranges except in prescribed places, largely for iteration.  Perhaps 
analagously, I discovered that webbrowser.open would open file URLs 
in their application on Macs (and perhaps Windows); when I suggested 
that behavior be added to the documentation of webbrowser what got 
added instead was a paragraph saying that although it might work it's 
neither supported nor portable. It could be that the right thing to 
do is instead of adding equality (though that would certainly be my 
preference) emphasize the statement that ranges have very little 
behavior, adding something like "in fact, two ranges are never equal" 
or something like that.

Either the documentation or the implementation should be changed -- 
it's just too much of a surprised to find that ranges aren't ever 
equal, especially when they were in Python 2.  (I'm still not 
claiming I can think of any logical reason for testing the equality 
of ranges. I stumbled on this while writing up a list of examples 
motivating pickling and trying to show for what kinds of values 
eval(str(value)) == value. I expected range to be one of them.

Here's another wrench, though: while a file is treated as a sequence 
of lines in for statements, I doubt anyone would want to ever compare 
files for equality. Possibly identity, to see if two open files are 
the same, but comparing the contents? That should be done under the 
program's control.

Sorry for the long-winded response. It wouldn't be as important if 
this were some corner of a little-used module, but range is really 
fundamental and it's better to get this right ASAP before people 
moving to Python 3 trip over it or rely on a behavior that might 
change in the future.
-- 
-- 

         --- Mitchell

----------
Added file: http://bugs.python.org/file13933/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________
-------------- next part --------------
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [issue5953] Add to &quot;whats new&quot;:
range(n) != range(n)</title></head><body>
<div>Yes, that's why I was surprised. It's rare (isn't it?) to have
str(a) == str(b) but a != b.&nbsp; a not is b, sure, but a != b? Note
also that list(range(n)) == list(range(n)). If the lists are equal and
the strings are equal it's hard to see why the objects wouldn't be
equal.</div>
<div><br></div>
<div>There are other things like range that define equality; for
instance</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>date.today() == datetime.date(2009, 5, 8)</div>
<div>Seems like ranges should define equals too.</div>
<div><br></div>
<div>However, I do understand the technical argument for saying not to
use ranges except in prescribed places, largely for iteration.&nbsp;
Perhaps analagously, I discovered that webbrowser.open would open file
URLs in their application on Macs (and perhaps Windows); when I
suggested that behavior be added to the documentation of webbrowser
what got added instead was a paragraph saying that although it might
work it's neither supported nor portable. It could be that the right
thing to do is instead of adding equality (though that would certainly
be my preference) emphasize the statement that ranges have very little
behavior, adding something like &quot;in fact, two ranges are never
equal&quot; or something like that.</div>
<div><br></div>
<div>Either the documentation or the implementation should be changed
-- it's just too much of a surprised to find that ranges aren't ever
equal, especially when they were in Python 2.&nbsp; (I'm still not
claiming I can think of any logical reason for testing the equality of
ranges. I stumbled on this while writing up a list of examples
motivating pickling and trying to show for what kinds of values
eval(str(value)) == value. I expected range to be one of them.</div>
<div><br></div>
<div>Here's another wrench, though: while a file is treated as a
sequence of lines in for statements, I doubt anyone would want to ever
compare files for equality. Possibly identity, to see if two open
files are the same, but comparing the contents? That should be done
under the program's control.</div>
<div><br></div>
<div>Sorry for the long-winded response. It wouldn't be as important
if this were some corner of a little-used module, but range is really
fundamental and it's better to get this right ASAP before people
moving to Python 3 trip over it or rely on a behavior that might
change in the future.</div>
<div><tt>-- </tt></div>

<div>-- <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --- Mitchell</div>
</body>
</html>

From report at bugs.python.org  Fri May  8 21:38:46 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 May 2009 19:38:46 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241811526.66.0.0894277186359.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Ok, so I was running "test_asyncore" and not "test_asynchat".

The issue on OS X is that when a new socket is connecting, select.poll() 
shows the socket as being writable when it first connects, but using my 
variant, .connected is False while it's waiting for the connection.

Options:
If we swap the pollin/pollout conditions, that would fix the hang on 
mac, but cause the hang on others (I'm not really worried about not 
doing a write after a read, .push() in asynchat performs an immediate 
send).

If we get rid of the .connected check, then when a .read() fails and 
causes a close, then we get an exception in handle_write().

If we swap to Giampaolo's variant, then we could lose data that was 
legitimately sent by a client.

I've got a version that doesn't hang on OS X, and should work on all 
platforms.  It's ugly, but it works.

----------
Added file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 21:38:56 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 May 2009 19:38:56 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241811536.84.0.313268598747.issue5798@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file13915/asyncore_fix_mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 21:39:31 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 May 2009 19:39:31 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241811571.63.0.147128240854.issue5798@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file13918/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 21:51:24 2009
From: report at bugs.python.org (Jonathan Hayward)
Date: Fri, 08 May 2009 19:51:24 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1241812284.05.0.0356155304298.issue5238@psf.upfronthosting.co.za>


Jonathan Hayward <jonathan.hayward at pobox.com> added the comment:

Is there a workaround to close a TLS socket and its underlying socket?

I was making something to use https for a simple operation, and it the
browser acted as if the socket never closed. If I followed the close of
the ssl socket by a close of the underlying socket, I didn't get errors,
but the browser throbber acted as if the connection was still open.

Jonathan, http://JonathansCorner.com/

----------
nosy: +JonathansCorner.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Fri May  8 22:06:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 May 2009 20:06:34 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241813194.31.0.41966407511.issue5798@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

asyncore_fix_mac_2.patch fixes all test_failures for me, on both trunk and 
py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 22:30:10 2009
From: report at bugs.python.org (Constantine Sapuntzakis)
Date: Fri, 08 May 2009 20:30:10 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1241812284.05.0.0356155304298.issue5238@psf.upfronthosting.co.za>
Message-ID: <ea59786f0905081330x47989ff4n1271c69f57205fcd@mail.gmail.com>


Constantine Sapuntzakis <csapuntz at gmail.com> added the comment:

Here is the workaround I'm using until the code gets fixed:

import ssl

# Work around python bug #5328
def SSLSocket_makefile_fixed(self, mode='r', bufsize=-1):
    from socket import _fileobject

    self._makefile_refs += 1
    return _fileobject(self, mode, bufsize, True)

ssl.SSLSocket.makefile = SSLSocket_makefile_fixed

An alternate way to fix it is to reach in to the _fileobject wrapper and
close the underlying
implementation:

In the do_GET() method of my web server I called:

self.rfile._sock.close()
self.wfile._sock.close()

-Costa

On Fri, May 8, 2009 at 12:51 PM, Jonathan Hayward <report at bugs.python.org>wrote:

>
> Jonathan Hayward <jonathan.hayward at pobox.com> added the comment:
>
> Is there a workaround to close a TLS socket and its underlying socket?
>
> I was making something to use https for a simple operation, and it the
> browser acted as if the socket never closed. If I followed the close of
> the ssl socket by a close of the underlying socket, I didn't get errors,
> but the browser throbber acted as if the connection was still open.
>
> Jonathan, http://JonathansCorner.com/
>
> ----------
> nosy: +JonathansCorner.com
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5238>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file13935/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________
-------------- next part --------------
Here is the workaround I&#39;m using until the code gets fixed:<br><br>import ssl<br><br># Work around python bug #5328<br>def SSLSocket_makefile_fixed(self, mode=&#39;r&#39;, bufsize=-1):<br>?????? from socket import _fileobject<br>
?????? <br>?????? self._makefile_refs += 1<br>?????? return _fileobject(self, mode, bufsize, True)<br><br>ssl.SSLSocket.makefile = SSLSocket_makefile_fixed<br><br><br>An alternate way to fix it is to reach in to the _fileobject wrapper and close the underlying<br>
implementation:<br><br>In the do_GET() method of my web server I called:<br><br>self.rfile._sock.close()<br>self.wfile._sock.close()<br><br>-Costa<br><br><br><div class="gmail_quote">On Fri, May 8, 2009 at 12:51 PM, Jonathan Hayward <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Jonathan Hayward &lt;<a href="mailto:jonathan.hayward at pobox.com">jonathan.hayward at pobox.com</a>&gt; added the comment:<br>
<br>
Is there a workaround to close a TLS socket and its underlying socket?<br>
<br>
I was making something to use https for a simple operation, and it the<br>
browser acted as if the socket never closed. If I followed the close of<br>
the ssl socket by a close of the underlying socket, I didn&#39;t get errors,<br>
but the browser throbber acted as if the connection was still open.<br>
<br>
Jonathan, <a href="http://JonathansCorner.com/" target="_blank">http://JonathansCorner.com/</a><br>
<br>
----------<br>
nosy: +JonathansCorner.com<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue5238" target="_blank">http://bugs.python.org/issue5238</a>&gt;<br>
_______________________________________<br>
</blockquote></div><br>

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: [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 22:57:50 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 May 2009 20:57:50 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241816270.56.0.297536045965.issue5798@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Here's an option that doesn't use .connected, which some people have 
expressed distaste for.

def readwrite(obj, flags):
    try:
        if flags & select.POLLIN:
            obj.handle_read_event()
        if flags & select.POLLOUT:
            obj.handle_write_event()
        if flags & select.POLLPRI:
            obj.handle_expt_event()
        if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL):
            obj.handle_close()
    except socket.error, e:
        if e.args[0] not in (EBADF, ECONNRESET, ENOTCONN, ESHUTDOWN, 
ECONNABORTED):
            obj.handle_error()
        else:
            obj.handle_close()
    except _reraised_exceptions:
        raise
    except:
        obj.handle_error()

It works on OS X and should work just as well on other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Fri May  8 23:02:10 2009
From: report at bugs.python.org (Cary R.)
Date: Fri, 08 May 2009 21:02:10 +0000
Subject: [issue5961] Missing labelside option for Tix option menu (fix
	included)
In-Reply-To: <1241721915.71.0.611768472614.issue5961@psf.upfronthosting.co.za>
Message-ID: <1241816530.3.0.536606600572.issue5961@psf.upfronthosting.co.za>


Changes by Cary R. <cygcary at yahoo.com>:


----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5961>
_______________________________________

From report at bugs.python.org  Fri May  8 23:08:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 May 2009 21:08:40 +0000
Subject: [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: <1241816920.93.0.303344186818.issue5971@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vsajip
nosy: +vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5971>
_______________________________________

From report at bugs.python.org  Fri May  8 23:15:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 May 2009 21:15:30 +0000
Subject: [issue5933] fix gcc -Wextra warnings (compare signed/unsigned)
In-Reply-To: <1241483099.83.0.567307070398.issue5933@psf.upfronthosting.co.za>
Message-ID: <1241817330.7.0.132008015929.issue5933@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r72479, r72481, r72482, r72483.

As a side note, I'm not 100% convinced of the correctness of the resource_setrlimit code.  If rlim_t is smaller than an unsigned long then input values might be wrapped to a smaller 
value (by the implicit long -> rlim_t conversion) when they should be signaling 
OverflowError instead.  Perhaps there should be a bunch of PySAFE_DOWNCASTs here?

Or maybe rlim_t is never smaller than a long in practice.

About RLIM_INFINITY:  I can't find it documented anywhere that RLIM_INFINITY is (rlim_t)-1, 
though I dare say that's true on many platforms.  Still, it doesn't seem like a safe 
assumption.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5933>
_______________________________________

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: [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: [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  Fri May  8 23:47:29 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Fri, 08 May 2009 21:47:29 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241819249.23.0.164637125937.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Actually I think the problem (see the attached file susebuild.log) is 
in the module time.so: during the build the python interpreter has not 
access to it (it is dynamically loaded) and it fails.

If that works is because an already python is set in the system (and 
the ./configure prefix is set to /usr): on the suse build server the 
system is regenerated from scratch every time making possible to catch 
this sort of side effects.

This way to build it is called continuous integration and it works 
forcing a hands-off approach to the build-install-test cycle (I cannot 
stress enough about the impressive work done by the SuSE people).

I'll fire tonight a new build on the suse build server with the latest 
patch and a small smoke test (is should catch the most obvious errors).
But are you convinced about the need for the "import pdb; pdb.set_trace
()"? 

If everything goes fine the latest build should be in:

http://download.opensuse.org/repositories/home:/cavallo71:/python-opt

Moreover there are few external modules compiled using this "new" 
interpreter (imaging and setuptools at the moment): this should give a 
reasonable confidence the distutils is not broken after changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Fri May  8 23:55:47 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 08 May 2009 21:55:47 +0000
Subject: [issue5959] PyCode_NewEmpty
In-Reply-To: <1241720694.59.0.328707962514.issue5959@psf.upfronthosting.co.za>
Message-ID: <1241819747.49.0.11879214772.issue5959@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Documented, tested, and committed to 2.7 as r72487.  This should be
forward-ported to 3.x also, but since we've already started the betas
for 3.1, it should probably wait for 3.2.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5959>
_______________________________________

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: =?utf-8?q?=5Bissue5974=5D_unicode_decode_error_due_to_improperly_entered_?=
	=?utf-8?b?dGV4dCAiTWFydGluIHYuIEzDtndpcyI=?=
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:20:05 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 08 May 2009 22:20:05 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1241821205.26.0.101831813306.issue5798@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Even if that patch would fix this issue (and I'm pretty sure it does) I
don't think it's a good idea handling all those errors (EBADF,
ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED) in readwrite() function.

Although those error codes unmistakably remark a disconnect event
condition (EBADF too? are we sure it *always* means that?) I would
prefer that be done in asyncore.dispatcher() and handle_close() be
called from there.

That's the implementation asyncore has always used until now where the
poller logic (poll(), poll2()) has always been kept separated from the
connection logic (asyncore.dispatcher) where the "if socket.err[0] in
..." stuff is done.


Unfortunately I haven't got an OS X box to test against and verify by
myself, but If I'm not mistaken by looking at the traceback messages
pasted by other folks, it seems that the exception takes place in
handle_expt_event() at this point:

err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)

If that's the case I think it makes more sense catching EBADF from there
rather than breaking the logic used so far, also because, if I'm not
mistaken, the problem has been introduced by this very line which has
been added in Python 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5798>
_______________________________________

From report at bugs.python.org  Sat May  9 00:25:05 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 08 May 2009 22:25:05 +0000
Subject: [issue5954] PyFrame_GetLineNumber
In-Reply-To: <1241679764.04.0.154044942183.issue5954@psf.upfronthosting.co.za>
Message-ID: <1241821505.29.0.110252377817.issue5954@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Documented and committed as r72488. This should be forward-ported to 3.x
also, but since we've already started the betas for 3.1, it should
probably wait for 3.2.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5954>
_______________________________________

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: [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 report at bugs.python.org  Sat May  9 00:42:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 08 May 2009 22:42:04 +0000
Subject: =?utf-8?q?=5Bissue5974=5D_unicode_decode_error_due_to_improperly_entered_?=
	=?utf-8?b?dGV4dCAiTWFydGluIHYuIEzDtndpcyI=?=
In-Reply-To: <1241820703.89.0.000181107829527.issue5974@psf.upfronthosting.co.za>
Message-ID: <1241822524.64.0.0410498847905.issue5974@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file13937/issue5974.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5974>
_______________________________________

From report at bugs.python.org  Sat May  9 01:36:04 2009
From: report at bugs.python.org (Campbell Barton)
Date: Fri, 08 May 2009 23:36:04 +0000
Subject: [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: <1241825764.19.0.991123556809.issue5967@psf.upfronthosting.co.za>


Changes by Campbell Barton <ideasman42 at gmail.com>:


Removed 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  Sat May  9 01:36:45 2009
From: report at bugs.python.org (Campbell Barton)
Date: Fri, 08 May 2009 23:36:45 +0000
Subject: [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: <1241825805.44.0.031736559103.issue5967@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

added to setslice too, fixed spelling error.

----------
Added file: http://bugs.python.org/file13938/slice.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5967>
_______________________________________

From report at bugs.python.org  Sat May  9 02:33:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 May 2009 00:33:47 +0000
Subject: [issue2660] Py3k fails to parse a file with an iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1241829227.15.0.220859726772.issue2660@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r72491.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2660>
_______________________________________

From report at bugs.python.org  Sat May  9 06:21:19 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 09 May 2009 04:21:19 +0000
Subject: [issue5966] unnecessary hardlink
In-Reply-To: <1241767950.78.0.669934246491.issue5966@psf.upfronthosting.co.za>
Message-ID: <1241842879.8.0.482729835534.issue5966@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

python3.1 or python2.6 has always been a "hardlink" to the python in the
same directory.
You will see that 
$(LN) python$(VERSION)$(EXE) $(PYTHON)

The one you find as 'softlink' for python2.5 is perhaps ubuntu way of
doing it.
Python installation from source for (Python2.5 also) creates hardlink
only, so this is working as designed.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5966>
_______________________________________

From report at bugs.python.org  Sat May  9 06:23:15 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 09 May 2009 04:23:15 +0000
Subject: [issue5966] unnecessary hardlink
In-Reply-To: <1241767950.78.0.669934246491.issue5966@psf.upfronthosting.co.za>
Message-ID: <1241842995.31.0.546076657142.issue5966@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5966>
_______________________________________

From report at bugs.python.org  Sat May  9 06:23:58 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 09 May 2009 04:23:58 +0000
Subject: [issue5966] unnecessary hardlink
In-Reply-To: <1241767950.78.0.669934246491.issue5966@psf.upfronthosting.co.za>
Message-ID: <1241843038.23.0.43847984045.issue5966@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5966>
_______________________________________

From report at bugs.python.org  Sat May  9 06:25:03 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 09 May 2009 04:25:03 +0000
Subject: [issue5966] unnecessary hardlink
In-Reply-To: <1241767950.78.0.669934246491.issue5966@psf.upfronthosting.co.za>
Message-ID: <1241843103.77.0.454684986319.issue5966@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
resolution: invalid -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5966>
_______________________________________

From report at bugs.python.org  Sat May  9 08:24:38 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 May 2009 06:24:38 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1241850277.05.0.829330279082.issue5953@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please don't post html.  For whatever reason, it displayed as
hard-to-read marked-up html text when emailed (and my reader does
usually display html messages properly).  Perhaps the email mime-type
was wrong even though it looks ok in Firefox.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  9 09:13:39 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 09 May 2009 07:13:39 +0000
Subject: =?utf-8?q?=5Bissue5974=5D_unicode_decode_error_due_to_improperly_entered_?=
	=?utf-8?b?dGV4dCAiTWFydGluIHYuIEzDtndpcyI=?=
In-Reply-To: <1241820703.89.0.000181107829527.issue5974@psf.upfronthosting.co.za>
Message-ID: <1241853219.79.0.526807574302.issue5974@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Fixed in r72496.

----------
nosy: +loewis
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5974>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 10:03:24 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 08:03:24 +0000
Subject: [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: <1241856204.65.0.634317306816.issue5900@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I including the patch right now. I a changing minor things (adding the
missing configure and renaming tests)

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5900>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 10:31:01 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 08:31:01 +0000
Subject: [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: <1241857861.4.0.890461240266.issue5900@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72497 in trunk. (tests run under macos, debian and win)

I'll wait 2 hours to watch the buildbots then I'll propagate it to the
py3k branch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5900>
_______________________________________

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: [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 11:48:38 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Sat, 09 May 2009 09:48:38 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241862518.09.0.584097913342.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Hi,
the latest patch (custom-log.diff minus the import logging
at the begin) breaks the imaging python module build:
the log is in the file susebuild.failed.imaging.log.

----------
Added file: http://bugs.python.org/file13939/susebuild.failed.imaging.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 12:10:26 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 10:10:26 +0000
Subject: [issue5976] test_os fails if run after test_distutils
In-Reply-To: <1241862490.7.0.561537062217.issue5976@psf.upfronthosting.co.za>
Message-ID: <1241863826.17.0.129907842422.issue5976@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

fixed in r72500 and r72502

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5976>
_______________________________________

From report at bugs.python.org  Sat May  9 13:13:54 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Sat, 09 May 2009 11:13:54 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241867634.05.0.0122591473891.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Hi Tarek,

there is a colliding warn symbol: one defiend whiting import warnings 
as warn and another defined as warn = logger.warn (~ line 56).

It breaks all the modules build (see attached file 
susebuild.failed.imaging-2.log).

As soon I confirm the patch I'll publish the modified version (it is 
now building).

----------
Added file: http://bugs.python.org/file13940/susebuild.failed.imaging-2.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 13:56:21 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 11:56:21 +0000
Subject: [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: <1241870181.9.0.420081577495.issue5900@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in py3k in r72504


Thanks Floris !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5900>
_______________________________________

From report at bugs.python.org  Sat May  9 14:17:08 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 May 2009 12:17:08 +0000
Subject: [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: <1241871428.88.0.600560333573.issue5971@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and release26-maint.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5971>
_______________________________________

From report at bugs.python.org  Sat May  9 14:43:16 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 09 May 2009 12:43:16 +0000
Subject: [issue1578269] Add os.link() and os.symlink() support for Windows
Message-ID: <1241872996.41.0.0792254008691.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

If I produce a patch for Python 3.1, can this capability possibly be
included in the release?  Are there any objections to the implementation
as found in jaraco.windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

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: [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 =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 15:36:40 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 13:36:40 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1241876200.89.0.367701655931.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

can you provide a test case that demonstrates the problem ?

----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May  9 15:38:20 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 09 May 2009 13:38:20 +0000
Subject: [issue1578269] Add os.link() and os.symlink() support for Windows
Message-ID: <1241876300.54.0.463535484822.issue1578269@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

With 3.1b1 already released, most likely this is too late for 3.1
(unless there would be a second beta, which is currently not planned).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May  9 15:39:41 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 13:39:41 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241876381.48.0.634971085946.issue3992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Antonio, I am starting to think that having distutils dependencies in
site.py smells bad.

I have sent a mail in python-dev about it, that is now discussed in
python-ideas to discuss the creation of a separated sysconfig module.

So this patch will be held until we take a decision for sysconfig.

Thanks for your work so far !

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Sat May  9 16:10:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 09 May 2009 14:10:12 +0000
Subject: [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: <1241878212.41.0.089163775566.issue5908@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With python, the first "import" of a library runs its initialization
code. Subsequent imports only retrieves the module object from the memory.

> for this library, it matter where you import the thing.

More precisely: it matters where you *first* import the thing. the
pyatspi import function probably runs some code that depends on the
running thread.
This is a common issue for event-driven libraries, often resolved by
splitting the initialization into two phases, the "import" phase and an
"init" function that performs thread-sensitive things.
You should forward your problem to the pyatspi team.

Since your first example works correctly, I close this issue as "works
for me".

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5908>
_______________________________________

From report at bugs.python.org  Sat May  9 16:37:35 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 09 May 2009 14:37:35 +0000
Subject: [issue1483545] Wave.py support for ulaw and alaw audio
Message-ID: <1241879855.38.0.357452633861.issue1483545@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please read http://www.python.org/dev/patches/
The best format for a patch is a "diff -u" format. It's much much easier
to see what you changed to the existing code, and the same patch often
applies to several versions.
Also, 2.4 and 2.5 are closed for new developments - your changes would
only go to a 2.7 version.

And your change is more likely to be accepted if it contains unit tests
(in Lib/test/test_wave.py)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483545>
_______________________________________

From report at bugs.python.org  Sat May  9 16:58:19 2009
From: report at bugs.python.org (Jonathan)
Date: Sat, 09 May 2009 14:58:19 +0000
Subject: [issue4938] Pdb cannot access doctest source in postmortem
In-Reply-To: <1231887344.64.0.130142534031.issue4938@psf.upfronthosting.co.za>
Message-ID: <1241881099.02.0.278315712858.issue4938@psf.upfronthosting.co.za>


Jonathan <jonathan.cervidae at gmail.com> added the comment:

#!/usr/bin/env python
# This does what you want. Change pydb for pdb if you prefer it.
import pydb
import doctest
import sys
sys.excepthook = pydb.exception_hook
try:
    doctest.testfile("story.txt",verbose=False,raise_on_error=True)
except doctest.UnexpectedException, failure:
    pass
exc_info = failure.exc_info
raise exc_info[0], exc_info[1], exc_info[2]

----------
nosy: +jonathan.cervidae

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4938>
_______________________________________

From report at bugs.python.org  Sat May  9 17:11:40 2009
From: report at bugs.python.org (Jonathan)
Date: Sat, 09 May 2009 15:11:40 +0000
Subject: [issue4938] Pdb cannot access doctest source in postmortem
In-Reply-To: <1231887344.64.0.130142534031.issue4938@psf.upfronthosting.co.za>
Message-ID: <1241881900.87.0.448597470243.issue4938@psf.upfronthosting.co.za>


Jonathan <jonathan.cervidae at gmail.com> added the comment:

#!/usr/bin/env python
# Slight mistake in last post
import pydb
import doctest
import sys
sys.excepthook = pydb.exception_hook
try:
    doctest.testfile("story.txt",verbose=False,raise_on_error=True)
except doctest.UnexpectedException, failure:
    exc_info = failure.exc_info
    raise exc_info[0], exc_info[1], exc_info[2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4938>
_______________________________________

From report at bugs.python.org  Sat May  9 17:30:01 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Sat, 09 May 2009 15:30:01 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1241883001.05.0.315186676193.issue3992@psf.upfronthosting.co.za>


Antonio Cavallo <a.cavallo at cavallinux.eu> added the comment:

Hi Tarek,

This is the latest patch to log.py that compiles with the latest python 
svn 72494. It shows no problem with the few modules I've used so far: 
now I can't decide if this should go mainline or not but I'll leave 
here as reference anyway.
Cheers,
Antonio

----------
Added file: http://bugs.python.org/file13942/custom-log-000.dif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Sat May  9 20:14:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 May 2009 18:14:28 +0000
Subject: [issue5973] re-usable generators / generator expressions should
	return iterables
In-Reply-To: <1241817979.06.0.302346555746.issue5973@psf.upfronthosting.co.za>
Message-ID: <1241892868.1.0.759949817891.issue5973@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You might be interested to read about this package:

http://www.fiber-space.de/generator_tools/doc/generator_tools.html

For anything to happen in this area you'd need to get some consensus on
python-ideas first.  If you do that, you can open a new ticket
referencing the python-ideas thread (or even reopen this one if that
seems appropriate).

----------
nosy: +r.david.murray
resolution:  -> rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5973>
_______________________________________

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: [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: [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:15:24 2009
From: report at bugs.python.org (kxroberto)
Date: Sat, 09 May 2009 19:15:24 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1241896524.8.0.128259318213.issue5977@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

>>> test_build_ext: The test must be run in a python build dir

don't have a build setup currently. maybe in future.

One can yet see in build_ext.py:

after "if self.inplace:" (line485)
there are 2 different computations for ext_filename

while computation in get_outputs() is not aware of self.inplace (line447

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From report at bugs.python.org  Sat May  9 21:21:01 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 09 May 2009 19:21:01 +0000
Subject: [issue5797] there is en exception om Create User page
In-Reply-To: <1240200084.56.0.449706089015.issue5797@psf.upfronthosting.co.za>
Message-ID: <1241896861.48.0.277800884219.issue5797@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> low
status: open -> pending
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5797>
_______________________________________

From report at bugs.python.org  Sat May  9 21:24:00 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 09 May 2009 19:24:00 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241850277.05.0.829330279082.issue5953@psf.upfronthosting.co.za>
Message-ID: <p06240801c62b84e21209@[192.168.1.107]>


Mitchell Model <mlm at acm.org> added the comment:

Sorry -- I did notice in the copies sent to me of my replies to bugs.python.org that there was HTML, but I can't  figure out why. I didn't use any style text in the message nor in my signature. I thought my email program only sent HTML when there was some styled text in the message. I just changed a setting that might fix this -- please tell me if you are seeing HTML in this.
-- 
-- 

        --- Mitchell

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

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: [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: [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 22:43:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 May 2009 20:43:23 +0000
Subject: [issue5981] float.fromhex bugs
In-Reply-To: <1241898617.16.0.557804357136.issue5981@psf.upfronthosting.co.za>
Message-ID: <1241901803.0.0.0497262039989.issue5981@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file13945/issue5981.patch

_______________________________________
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: [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: [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 report at bugs.python.org  Sat May  9 23:28:53 2009
From: report at bugs.python.org (schmirrwurst)
Date: Sat, 09 May 2009 21:28:53 +0000
Subject: [issue5983] boolean.so no more in _xmlplus/utils
In-Reply-To: <1241904507.75.0.715098012356.issue5983@psf.upfronthosting.co.za>
Message-ID: <1241904533.16.0.663752157555.issue5983@psf.upfronthosting.co.za>


Changes by schmirrwurst <schmirrwurst at free.fr>:


----------
components: +XML
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5983>
_______________________________________

From report at bugs.python.org  Sat May  9 23:44:48 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 May 2009 21:44:48 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <p06240801c62b84e21209@[192.168.1.107]>
Message-ID: <4A05F943.6070909@udel.edu>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Mitchell Model wrote:
> Mitchell Model <mlm at acm.org> added the comment:
> 
> Sorry -- I did notice in the copies sent to me of my replies to
> bugs.python.org that there was HTML, but I can't  figure out why. I
> didn't use any style text in the message nor in my signature. I
> thought my email program only sent HTML when there was some styled
> text in the message. I just changed a setting that might fix this --
> please tell me if you are seeing HTML in this.

No, looks great.  I believe for most (all?) mailers, '[x] sent html' 
*always* sends html, even if not 'needed'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 10 00:39:02 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 09 May 2009 22:39:02 +0000
Subject: [issue5983] boolean.so no more in _xmlplus/utils
In-Reply-To: <1241904507.75.0.715098012356.issue5983@psf.upfronthosting.co.za>
Message-ID: <1241908742.3.0.478133190602.issue5983@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This bug tracker is for Python, not for the PyXML package (where
boolean.so comes from).

Closing as invalid.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5983>
_______________________________________

From report at bugs.python.org  Sun May 10 01:02:01 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 09 May 2009 23:02:01 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241910121.89.0.040680463719.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, here is an attempt to fix this. My guess is it has something to do
with sys.dont_write_bytecode, otherwise I cannot understand why you fail
and not someone else since no other case-sensitive systems have reported
this failure.

----------
status: open -> pending
Added file: http://bugs.python.org/file13946/skip_bytecode_writing.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Sun May 10 08:59:41 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 10 May 2009 06:59:41 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241938781.52.0.650888020838.issue5442@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

1 Fail:

test test_importlib crashed -- <class 'AttributeError'>: 'module' object 
has no attribute 'writes_bytecode'
Traceback (most recent call last):
  File "/Users/cartman/Python-3.1b1/Lib/test/regrtest.py", line 620, in 
runtest_inner
    indirect_test()
  File "/Users/cartman/Python-3.1b1/Lib/test/test_importlib.py", line 6, 
in test_main
    run_unittest(importlib.test.test_suite('importlib.test'))
  File "/Users/cartman/Python-3.1b1/Lib/importlib/test/__init__.py", 
line 22, in test_suite
    package_tests = getattr(sys.modules[package_name], 'test_suite')()
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/__init__.py", line 8, in test_suite
    return importlib.test.test_suite('importlib.test.source', directory)
  File "/Users/cartman/Python-3.1b1/Lib/importlib/test/__init__.py", 
line 16, in test_suite
    __import__(module_name, level=0)
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_file_loader.py", line 111, in 
<module>
    class BadBytecodeTest(unittest.TestCase):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_file_loader.py", line 130, in 
BadBytecodeTest
    @source_util.writes_bytecode
AttributeError: 'module' object has no attribute 'writes_bytecode'
1 test failed:
    test_importlib

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

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: [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: [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 12:37:10 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 10 May 2009 10:37:10 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1241951830.86.0.45997319375.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I see now that symlink is defined in posixmodule.c (which ends up as the
builtin module 'nt').

Then, in os.py, there's a short section that does effectively 'from nt
import *'.

Would it be unreasonable for a patch to add a new Python module
(something like _nt_supplemental.py or platform_windows.py) which
exposes symlink() and islink(), and then in os.py to import those
functions into the os namespace at the same time as importing the
functions from the nt namespace?

My reasoning here is twofold:

1) I don't want to additionally complicate posixmodule.c, and since
Windows doesn't have a posix symlink function, this doesn't seem like
the appropriate place anyway.
2) I don't want to clutter os.py with os-specific code.

This brings up two questions.

1) Is there a problem with the os module exposing names that aren't in
posixmodule.c, but are platform-specific?  I suspect not, but I want to
consider the possibility.
2) Where would be a good location for the platform-specific pure-python
module?  If there's no guidance, I'll just pick something and it can be
relocated (as necessary) when the patch is applied.

----------
title: Add os.link() and os.symlink() support for Windows -> Add os.link() and os.symlink() and os.path.islink() support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 10 12:41:24 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 10:41:24 +0000
Subject: [issue5984] distutils.command.build_ext.check_extensions_list broken
	checkings
In-Reply-To: <1241948348.34.0.593994545103.issue5984@psf.upfronthosting.co.za>
Message-ID: <1241952084.22.0.40093663658.issue5984@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72531, r72532, r72533, r72534

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5984>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 10 12:41:57 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 10:41:57 +0000
Subject: [issue5984] distutils.command.build_ext.check_extensions_list broken
	checkings
In-Reply-To: <1241948348.34.0.593994545103.issue5984@psf.upfronthosting.co.za>
Message-ID: <1241952117.21.0.19949047992.issue5984@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

(the pending deprecation warning will be done separately)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5984>
_______________________________________

From report at bugs.python.org  Sun May 10 13:56:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 11:56:51 +0000
Subject: [issue5970] sys.exc_info leaks into a generator
In-Reply-To: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>
Message-ID: <1241956611.48.0.290122383327.issue5970@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding some tests to check that a bug is /not/ fixed looks weird to me.
If we did that for every trunk change that we don't want to end up in
the stable branch, there'd be lots of new tests of dubious utility.

Besides, py3k isn't affected ;)

----------
nosy: +pitrou
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5970>
_______________________________________

From report at bugs.python.org  Sun May 10 14:06:41 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 10 May 2009 12:06:41 +0000
Subject: [issue5970] sys.exc_info leaks into a generator
In-Reply-To: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>
Message-ID: <1241957201.49.0.290362729597.issue5970@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I agree with Antoine.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5970>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 10 14:26:48 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 12:26:48 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1241958408.85.0.436109367582.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I was talking about your use case (pyximport (Cython) do crash then ?)

If I can have a real example, with the output and the expected one,
I will build a test with it in Distutils before I fix it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From report at bugs.python.org  Sun May 10 16:31:33 2009
From: report at bugs.python.org (kxroberto)
Date: Sun, 10 May 2009 14:31:33 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1241965893.41.0.569280780062.issue5977@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

its with any .pyx (Cython) module , when after pyximport.install() and
injection of --inplace option a .pyx module is imported.

the relevant lines in pyxbuild.py are

        dist.run_commands()
        return dist.get_command_obj("build_ext").get_outputs()[0]

which use the buggy "get_outputs" and shall return the full path of
built module to pyximport.py :

    so_path = pyxbuild.pyx_to_dll(pyxfilename, extension_mod,
                                  build_in_temp=build_in_temp,
                                  pyxbuild_dir=pyxbuild_dir,
                                  setup_args=sargs )
    assert os.path.exists(so_path), "Cannot find: %s" % so_path

=> crash with "Cannot find..." before pyximport.load_module goes to
import it.

-

A stripped down test case should perhaps 'build_ext' any arbitrary
extension module with --inplace ( a option of base command 'build' ) and
something like ...

dist.get_command_obj("build_ext").inplace=1
dist.run_commands()
so_path = dist.get_command_obj("build_ext").get_outputs()[0]
assert os.path.isfile(so_path) and os.path.dirname(so_path) in ('','.')

... will produce a invalid so_path: not pointing to actual locally
in-place built xy.pyd/.so, but to a non-existing or old file in the
build folders

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From report at bugs.python.org  Sun May 10 17:22:37 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Sun, 10 May 2009 15:22:37 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241968957.72.0.701579070863.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

I think that the problem is: the xmldoc1 has the newline or not? If it
hasn't your patch works only in the particular case you pass a toxml
return value to 'parsestring'. If I pass an XML string with newlines it
doesn't work. So your solution is not generic and cannot be considered a
patch for the issue you proposed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Sun May 10 17:43:05 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 May 2009 15:43:05 +0000
Subject: [issue5979] strptime() gives inconsistent exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1241970185.29.0.84092435445.issue5979@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5979>
_______________________________________

From report at bugs.python.org  Sun May 10 18:24:22 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Sun, 10 May 2009 16:24:22 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241972662.24.0.736217789456.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

I try to explain better what is my opinion:
- If you add the attribute by using setAttribute the newlines are kept
and the toxml works well
- If you add the attribute by using the parsestring, passing it an XML
string the newlines are replaced

- Your patch works only if you act on a well-constructed (i.e.with
newlines kept in internal data structures) xml.dom.minidom.Document
object only, so...
- If you try to execute your patched toxml method of a
xml.dom.minidom.Document constructed using parsestring passing it a
string with newline it does not work.

So your patch works only in a specific case: you are trying to fix a
problem in parsestring, acting on its actual parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Sun May 10 18:34:33 2009
From: report at bugs.python.org (Tomalak)
Date: Sun, 10 May 2009 16:34:33 +0000
Subject: [issue5752] xml.dom.minidom does not handle newline characters in
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241973273.1.0.543750931833.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Francesco, I think you are missing the point. :-) The problem has two sides.

If I create an XML document using the DOM (not by parsing it from a
string!), then I can put newline characters into attribute value. This
is allowed and conforms to the XML spec. 

However, *literal* newlines in an attribute value (i.e. when the
document is parsed from a string) have no meaning. The parser treats
them as if they were insignificant whitespace -- they are converted to a
single space. This is also valid and conforms to the XML spec.

The catch: This leads to an actual data loss if I *wanted* to store
newline characters in an attribute -- unless the newline characters are
properly encoded. Encoding the newline characters is also valid and
conforms to the spec, so the DOM implementation should do it. 

In other words - the parsing process you refer to is actually working
fine. If an attribute contains a literal newline, it is indeed okay to
collapse it into a space. It's only the document serializing that is broken.

Minidom is clearly missing functionality here, and it does not conform
to the XML spec. If I store a string of data in an XML document, it must
be ensured that upon reading the document again, I get the *same* data
back. This is what I check with my test script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Sun May 10 18:40:42 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 10 May 2009 16:40:42 +0000
Subject: [issue5970] sys.exc_info leaks into a generator
In-Reply-To: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>
Message-ID: <1241973642.29.0.248066976666.issue5970@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Re py3k: oops, thanks for checking.

Re 2.6: Fine with me, second patch removed.

----------
assignee: barry -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5970>
_______________________________________

From report at bugs.python.org  Sun May 10 18:40:47 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 10 May 2009 16:40:47 +0000
Subject: [issue5970] sys.exc_info leaks into a generator
In-Reply-To: <1241804641.35.0.0131164077966.issue5970@psf.upfronthosting.co.za>
Message-ID: <1241973647.03.0.478560783434.issue5970@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin <jyasskin at gmail.com>:


Removed file: http://bugs.python.org/file13928/exc_info_26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5970>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 10 19:12:45 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 10 May 2009 17:12:45 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
In-Reply-To: <1241951830.86.0.45997319375.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4A070B08.7050808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Would it be unreasonable for a patch to add a new Python module
> (something like _nt_supplemental.py or platform_windows.py) which
> exposes symlink() and islink(), and then in os.py to import those
> functions into the os namespace at the same time as importing the
> functions from the nt namespace?

How would you provide access to the system functions in pure Python?
If you think of using ctypes, then yes, that would be unreasonable.

> 1) I don't want to additionally complicate posixmodule.c, and since
> Windows doesn't have a posix symlink function, this doesn't seem like
> the appropriate place anyway.

Don't worry about that. The purpose of posixmodule.c is to be
system-specific.

> 1) Is there a problem with the os module exposing names that aren't in
> posixmodule.c, but are platform-specific?  I suspect not, but I want to
> consider the possibility.

In general, the os module shouldn't expose any functions that are
platform-specific. That's the whole point of the os module.

People tend to access functions of the posix module that are specific
to POSIX through the os module, but it isn't really meant this way.

> 2) Where would be a good location for the platform-specific pure-python
> module?

See above. There can't be such a thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun May 10 19:26:20 2009
From: report at bugs.python.org (Tomalak)
Date: Sun, 10 May 2009 17:26:20 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1241976380.45.0.473831870206.issue5752@psf.upfronthosting.co.za>


Changes by Tomalak <M8R-t1tut01 at mailinator.com>:


----------
title: xml.dom.minidom does not handle newline characters in attribute values -> xml.dom.minidom does not escape newline characters within attribute values

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

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: [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 19:52:44 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 10 May 2009 17:52:44 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <4A070B08.7050808@v.loewis.de>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B674F4908CD5@hornigold.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> How would you provide access to the system functions in pure Python?
> If you think of using ctypes, then yes, that would be unreasonable.

Would you elaborate just a bit more on why a ctypes implementation would be 
undesirable?  "What's New" for Python 2.5 states that "Perhaps developers will 
begin to write Python wrappers atop a library accessed through ctypes instead 
of extension modules, now that ctypes is included with core Python."  I 
acknowledge that because we're talking about the core, the use of ctypes may 
be discouraged, but I have no strong reasons to think so.  I can see for 
consistency sake that it might be preferable to call the Windows C APIs 
directly, but that to me seems like unnecessary complication and maintenance 
trouble, whereas ctypes abstracts the exact same library calls in a 
compiler-agnostic way.  In my experience, ctypes has been invaluable providing 
robust and clean interfaces to otherwise unexposed APIs. As you can see in 
jaraco.windows.filesystem, I was able to implement link(), islink(), and 
symlink() in just a few dozen lines of Python.  It seems like unnecessary work 
to port this to CPython APIs surrounded by ifdefs and potentially introducing 
new compiler issues.

So, to be clear, I don't have the experience to assert that a ctypes 
implementation is a proper one, but I have little reason to think otherwise 
and would very much appreciate a little guidance on why I wouldn't want to use 
ctypes given the positive experiences I've had thus far.

> Don't worry about that. The purpose of posixmodule.c is to be
> system-specific.

After your answer, I suspect this will be the approach I'll take.

> In general, the os module shouldn't expose any functions that are
> platform-specific. That's the whole point of the os module.
>
> People tend to access functions of the posix module that are specific
> to POSIX through the os module, but it isn't really meant this way.

But isn't that the way to write future-proof portable code?  If one writes 
code that calls os.symlink, and a future version of Python supports symlink in 
Windows, then the library that calls os.symlink may just work in Windows 
without any rewrite.  Indeed, isn't that the primary purpose of the os module, 
to provide a unified interface to platform-specific implementations of the 
same behavior?

----------
title: Add os.link() and os.symlink() and os.path.islink() support for Windows -> Add os.link() and os.symlink() and os.path.islink()	support for Windows
Added file: http://bugs.python.org/file13948/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6998 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090510/bf6186f5/attachment.bin>

From report at bugs.python.org  Sun May 10 19:53:45 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 10 May 2009 17:53:45 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <4A070B08.7050808@v.loewis.de>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B674F4908CD6@hornigold.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> How would you provide access to the system functions in pure Python?
> If you think of using ctypes, then yes, that would be unreasonable.

Would you elaborate just a bit more on why a ctypes implementation would be
undesirable?  "What's New" for Python 2.5 states that "Perhaps developers will
begin to write Python wrappers atop a library accessed through ctypes instead
of extension modules, now that ctypes is included with core Python."  I
acknowledge that because we're talking about the core, the use of ctypes may
be discouraged, but I have no strong reasons to think so.  I can see for
consistency sake that it might be preferable to call the Windows C APIs
directly, but that to me seems like unnecessary complication and maintenance
trouble, whereas ctypes abstracts the exact same library calls in a
compiler-agnostic way.  In my experience, ctypes has been invaluable providing
robust and clean interfaces to otherwise unexposed APIs. As you can see in
jaraco.windows.filesystem, I was able to implement link(), islink(), and
symlink() in just a few dozen lines of Python.  It seems like unnecessary work
to port this to CPython APIs surrounded by ifdefs and potentially introducing
new compiler issues.

So, to be clear, I don't have the experience to assert that a ctypes
implementation is a proper one, but I have little reason to think otherwise
and would very much appreciate a little guidance on why I wouldn't want to use
ctypes given the positive experiences I've had thus far.

> Don't worry about that. The purpose of posixmodule.c is to be
> system-specific.

After your answer, I suspect this will be the approach I'll take.

> In general, the os module shouldn't expose any functions that are
> platform-specific. That's the whole point of the os module.
>
> People tend to access functions of the posix module that are specific
> to POSIX through the os module, but it isn't really meant this way.

But isn't that the way to write future-proof portable code?  If one writes
code that calls os.symlink, and a future version of Python supports symlink in
Windows, then the library that calls os.symlink may just work in Windows
without any rewrite.  Indeed, isn't that the primary purpose of the os module,
to provide a unified interface to platform-specific implementations of the
same behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun May 10 20:04:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 18:04:53 +0000
Subject: [issue5986] Avoid reversed() in Random.shuffle()
In-Reply-To: <1241976576.36.0.361405566006.issue5986@psf.upfronthosting.co.za>
Message-ID: <1241978693.48.0.660464181122.issue5986@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
stage:  -> patch review
type:  -> performance
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5986>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 10 20:14:46 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 10 May 2009 18:14:46 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <8B473FAE8A08C34C9F5666FD4B0A87B674F4908CD6@hornigold.jaraco.com>
Message-ID: <4A071990.2000603@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Would you elaborate just a bit more on why a ctypes implementation would be
> undesirable?

ctypes is inherently insecure. It must be possible to use Python itself
with ctypes removed. Therefore, there is a strict policy not to use
ctypes in the core.

>> People tend to access functions of the posix module that are specific
>> to POSIX through the os module, but it isn't really meant this way.
> 
> But isn't that the way to write future-proof portable code?  If one writes
> code that calls os.symlink, and a future version of Python supports symlink in
> Windows, then the library that calls os.symlink may just work in Windows
> without any rewrite.  Indeed, isn't that the primary purpose of the os module,
> to provide a unified interface to platform-specific implementations of the
> same behavior?

Correct - but for that to work, it should really only expose functions
that work on all systems. It currently fails to do so, allowing people
to write applications that they believe to be portable, but actually
aren't portable at all.

However, it has always been that way, so the added portability that the
os module provides is really minor. Instead, portability is already
provided in posixmodule.c

----------
title: Add os.link() and os.symlink() and os.path.islink()	support for Windows -> Add os.link() and os.symlink() and	os.path.islink() support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun May 10 20:53:42 2009
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 10 May 2009 18:53:42 +0000
Subject: [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: [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 21:03:27 2009
From: report at bugs.python.org (Farhan Ahmad)
Date: Sun, 10 May 2009 19:03:27 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1241982207.48.0.611472643711.issue4066@psf.upfronthosting.co.za>


Farhan Ahmad <farhan at thebitguru.com> added the comment:

Marcin, thanks for finding the cause.  I have attached another diff
that, instead of removing the assignment, makes the _get_socket function
return the socket, which is the expected behavior.

You mentioned that the LMTP class also has this issue.  I looked through
that class, but didn't see any similar issues.  Can you please give more
details?

Thanks,
Farhan

----------
nosy: +farhan.ahmad
Added file: http://bugs.python.org/file13949/smtplib_72551.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Sun May 10 21:39:32 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 May 2009 19:39:32 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241984372.73.0.690299374146.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Bah, I screwed up and left a file out of skip_bytecode_writing.diff. If
you apply test_file_loader along with that patch that should fix the error.

----------
Added file: http://bugs.python.org/file13950/test_file_loader.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Sun May 10 21:39:52 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 May 2009 19:39:52 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241984392.64.0.702704923527.issue5442@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Sun May 10 21:54:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 May 2009 19:54:07 +0000
Subject: [issue5987] Broken link to "Curses Programming with Python"
In-Reply-To: <1241981621.95.0.54234756767.issue5987@psf.upfronthosting.co.za>
Message-ID: <1241985247.99.0.806981764457.issue5987@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already fixed in later versions.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5987>
_______________________________________

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: [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:20:41 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Sun, 10 May 2009 20:20:41 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1241986841.96.0.393730727321.issue4066@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Your diff is better than mine and looks quite similar to patch number 2
in #4470. If the whole #4470 can't be accepted for now, we could at
least apply this one change, because without it SMTP_SSL is totally
unusable. Daniel, maybe we can mark this bug or #4470 as critical?

LMTP seems ok indeed; I don't remember why I mentioned it. :)

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Sun May 10 22:21:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:21:03 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1241986863.44.0.385080113944.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New results:

test_os leaked [1, 1] references, sum=2
test_urllib leaked [4, 2] references, sum=6
test_urllib2 leaked [227, 227] references, sum=454
test_urllib2_localnet leaked [3, 3] references, sum=6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Sun May 10 22:44:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:44:55 +0000
Subject: [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  Sun May 10 22:45:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:45:25 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1241988325.91.0.0321393058956.issue5596@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +Memory leak in os.rename() and other functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Sun May 10 22:49:45 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 10 May 2009 20:49:45 +0000
Subject: [issue5804] Add an 'offset' argument to zlib.decompress
In-Reply-To: <1240307503.01.0.128578916914.issue5804@psf.upfronthosting.co.za>
Message-ID: <1241988585.25.0.6675652926.issue5804@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5804>
_______________________________________

From report at bugs.python.org  Sun May 10 22:54:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:54:40 +0000
Subject: [issue2652] 64 bit python  memory leak usage
In-Reply-To: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>
Message-ID: <1241988880.05.0.629547940571.issue2652@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Closing since no further information was given about the workload.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2652>
_______________________________________

From report at bugs.python.org  Sun May 10 22:55:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:55:42 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1241988942.7.0.737413781922.issue5238@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file13935/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Sun May 10 22:56:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:56:11 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1241988971.41.0.404817241797.issue5238@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Bill, can you check if it's a real bug? Unclosed sockets are pretty bad.

----------
nosy: +pitrou
priority:  -> high
versions: +Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Sun May 10 22:58:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 20:58:04 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1241989084.36.0.192611804543.issue5964@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think it is the intended behaviour. Comparison for equality
should return either True or False (or perhaps NotImplemented?), not
raise a TypeError.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Sun May 10 23:01:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 21:01:51 +0000
Subject: [issue1739118] Investigated ref leak report related to thread
	regrtest.py
Message-ID: <1241989311.85.0.571010820403.issue1739118@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, rather than some C code in the internals, couldn't we simply
iterate over the registered Thread objects and join() on those which are
still running?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739118>
_______________________________________

From report at bugs.python.org  Sun May 10 23:02:20 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 10 May 2009 21:02:20 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1241989340.16.0.517833261332.issue5442@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Applied skip_bytecode.diff and test_file_loader.diff clean build 
results in:

======================================================================
FAIL: test_case_insensitivity 
(importlib.test.extension.test_case_sensitivity.ExtensionModuleCaseSensi
tivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/extension/test_case_sensitivity.py", line 29, 
in test_case_insensitivity
    self.assert_(hasattr(loader, 'load_module'))
AssertionError: False is not True

======================================================================
FAIL: test_insensitive 
(importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Python-
3.1b1/Lib/importlib/test/source/test_case_sensitivity.py", line 49, in 
test_insensitive
    self.assert_(hasattr(insensitive, 'load_module'))
AssertionError: False is not True

----------------------------------------------------------------------
Ran 166 tests in 0.124s

FAILED (failures=2)
test test_importlib failed -- errors occurred; run in verbose mode for 
details

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Sun May 10 23:02:57 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 10 May 2009 21:02:57 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1241989377.26.0.376268902481.issue4470@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +smtplib SMTP_SSL._get_socket doesn't return a value
priority:  -> high
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sun May 10 23:05:03 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 10 May 2009 21:05:03 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1241989503.31.0.442629188154.issue4066@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Marcin,
Done and set this one as a dependency of 4470. It would be very good to
have a test that flexes this patch, can you work on one?

----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Sun May 10 23:05:30 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 10 May 2009 21:05:30 +0000
Subject: [issue5804] Add an 'offset' argument to zlib.decompress
In-Reply-To: <1240307503.01.0.128578916914.issue5804@psf.upfronthosting.co.za>
Message-ID: <0016361e8962983c0304699538f5@google.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Overall, this looks good.  Some mostly minor comments in this review.

http://codereview.appspot.com/63060/diff/1/2
File Doc/library/zlib.rst (right):

http://codereview.appspot.com/63060/diff/1/2#newcode136
Line 136: When specified, it will cause the function's return value to
be a (uncompressed, offset)
how about this wording:

..."to be a tuple of (uncompressed, offset), with the"...

http://codereview.appspot.com/63060/diff/1/2#newcode142
Line 142: Added the *offset* argument
missing . at the end of the sentence.  Also, mention that this function
now accepts keyword arguments.

http://codereview.appspot.com/63060/diff/1/3
File Lib/test/test_zlib.py (right):

http://codereview.appspot.com/63060/diff/1/3#newcode110
Line 110: c = zlib.compress(a)+zlib.compress(b)
please surround the + with spaces for readability and consistency with
other code in the file.\

http://codereview.appspot.com/63060/diff/1/4
File Modules/zlibmodule.c (right):

http://codereview.appspot.com/63060/diff/1/4#newcode193
Line 193: "the start position in the string to start decompresion and,
if spceified,\n"
typo: specified.

http://codereview.appspot.com/63060/diff/1/4#newcode296
Line 296: offset = length-zst.avail_in+offset;
leave spaces around your - and + operators and this becomes easier to
read.

http://codereview.appspot.com/63060

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5804>
_______________________________________

From report at bugs.python.org  Sun May 10 23:14:41 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 10 May 2009 21:14:41 +0000
Subject: [issue5804] Add an 'offset' argument to zlib.decompress
In-Reply-To: <1240307503.01.0.128578916914.issue5804@psf.upfronthosting.co.za>
Message-ID: <1241990081.99.0.145943809642.issue5804@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Maybe I'm missing something, but isn't the offset parameter just another
way of spelling
buffer(input, offset)?

I like the avoiding of copying, just wondering if having a magic
parameter to get a tuple is really better than (say)
result, used = zlib.decompress2(source)
if used<len(source):
    result2, used = zlib.decompress2(buffer(source, used))

This changes two things. Rather than a magic parameter it adds a new
function which always returns tuples (meaning that you don't need magic
to make sure users don't accidentally pass offset=None and get a single
result when they wanted a tuple), and uses the built in buffer facility
to avoid copying rather than relying on delayed slicing.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5804>
_______________________________________

From report at bugs.python.org  Sun May 10 23:17:08 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Sun, 10 May 2009 21:17:08 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1241990228.02.0.105408311917.issue4066@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Here's a dumbed down version of the test from #4470. It requires
network, but no gmail account is needed to run the test.

----------
Added file: http://bugs.python.org/file13952/test_smtpnet.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Mon May 11 00:28:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 22:28:45 +0000
Subject: [issue5990] Memory leak in os.rename() and other functions
In-Reply-To: <1241988294.2.0.773567754843.issue5990@psf.upfronthosting.co.za>
Message-ID: <1241994525.02.0.544734850866.issue5990@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r72556.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5990>
_______________________________________

From report at bugs.python.org  Mon May 11 00:52:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 22:52:28 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1241995948.34.0.174262795028.issue5006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against py3k.

----------
Added file: http://bugs.python.org/file13953/append_bom-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Mon May 11 01:08:16 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 May 2009 23:08:16 +0000
Subject: [issue5989] unittest.TestLoader.loadTestsFromNames should accept
	module / class name
In-Reply-To: <1241985860.54.0.789290376595.issue5989@psf.upfronthosting.co.za>
Message-ID: <1241996896.1.0.356183927991.issue5989@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Actually they do - it is an obscure bug in the way the module is
specified in TestProgram that prevents this from working.

The code in parseArgs that is currently:

            if len(args) > 0:
                self.testNames = args

Should probably be:

            if len(args) > 0:
                self.testNames = args
                self.module = None

Anyway - I'll report and fix that as a separate issue. :-)

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5989>
_______________________________________

From report at bugs.python.org  Mon May 11 01:39:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 23:39:39 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1241998779.96.0.0851309805123.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems other projects are already fighting with the path-changing
behaviour of PySys_SetArgv(), e.g.:
- py2exe:
http://www.google.com/codesearch/p?hl=fr#QCS1naFbAGM/trunk/py2exe/source/start.c&q=PySys_SetArgv
- gtk:
http://www.google.com/codesearch/p?hl=fr#4d1DG_2vwJw/pygtk-2.10.4/gtk/__init__.py&q=PySys_SetArgv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

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: [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:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 23:56:51 +0000
Subject: [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 01:58:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 May 2009 23:58:45 +0000
Subject: [issue5992] spurious space after opening parenthesis when
	auto-completing
In-Reply-To: <1241999810.49.0.16520968517.issue5992@psf.upfronthosting.co.za>
Message-ID: <1241999925.05.0.31113530868.issue5992@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5992>
_______________________________________

From report at bugs.python.org  Mon May 11 02:00:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 11 May 2009 00:00:47 +0000
Subject: [issue5986] Avoid reversed() in Random.shuffle()
In-Reply-To: <1241976576.36.0.361405566006.issue5986@psf.upfronthosting.co.za>
Message-ID: <1242000047.24.0.0483910493174.issue5986@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5986>
_______________________________________

From report at bugs.python.org  Mon May 11 03:47:25 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 May 2009 01:47:25 +0000
Subject: [issue5442] test_importlib fails on Mac OSX 10.5.6 w/ case-sensitive
	file system
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1242006445.69.0.722572662442.issue5442@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, that means everything is fixed as case_sensitivity_tests.diff fixes
those test errors.

Committed in r72559.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5442>
_______________________________________

From report at bugs.python.org  Mon May 11 04:08:33 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 11 May 2009 02:08:33 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242007713.71.0.74563445658.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Here is a patch which will return False instead of TypeError. This is
the same behavior a normal set has. Two things though.

1. I don't know wether the 'import _abcoll' statement somehow influences
the bootstrap in one way or the other, because 'from _abcoll import
Iterable' does.

2. The current WeakSet implementation returns True if a WeakSet is
compared to any Iterable which contains the same set of objects:

>>> import weakref
>>>
>>> class Foo: pass
...
>>> l = [Foo(), Foo(), Foo()]
>>> ws = weakref.WeakSet(l)
>>> ws == l
True

Not sure wether this is intended, since this is not the same behavior of
a normal set. If it is intended, I think it should be documented.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file13955/_weakrefset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

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: [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 =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May 11 07:19:04 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 11 May 2009 05:19:04 +0000
Subject: [issue5990] Memory leak in os.rename() and other functions
In-Reply-To: <1241988294.2.0.773567754843.issue5990@psf.upfronthosting.co.za>
Message-ID: <1242019143.95.0.525864443225.issue5990@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The problem is more general. It can always happen that another argument
conversion fails after the O& conversion had failed. Instead of going
through the code and fixing each and every usage of the FSConverter
callback, I'd rather want to discuss a more general solution, where
PyArg_ParseTuple will invoke cleanup itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5990>
_______________________________________

From report at bugs.python.org  Mon May 11 09:13:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2009 07:13:02 +0000
Subject: [issue5986] Avoid reversed() in Random.shuffle()
In-Reply-To: <1241976576.36.0.361405566006.issue5986@psf.upfronthosting.co.za>
Message-ID: <1242025982.22.0.790383305749.issue5986@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on this patch.  Reversed has a very low overhead.  Readability if
more important.  The current code is self-evidently correct but the
patched code is less obviously so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5986>
_______________________________________

From report at bugs.python.org  Mon May 11 09:31:18 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Mon, 11 May 2009 07:31:18 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242027078.41.0.50618455353.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

All right, now I understand, thanks. But I think that, for internal
class coherence, it is necessary not to modify toxml method, but the
'setAttribute' one, because this is the source of the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Mon May 11 09:44:25 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2009 07:44:25 +0000
Subject: [issue5986] Avoid reversed() in Random.shuffle()
In-Reply-To: <1241976576.36.0.361405566006.issue5986@psf.upfronthosting.co.za>
Message-ID: <1242027865.93.0.47126907218.issue5986@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, the inefficiency is only in the loop setup, the time to call
reversed() and __reversed__().  The inner loop runs at the same speed
because xrange provides a __reversed__ iterator.

Please do not go through the standard library making these minor tweaks
without making sure there is a significant measured speed-up and do
consider the readability issue.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5986>
_______________________________________

From report at bugs.python.org  Mon May 11 09:56:32 2009
From: report at bugs.python.org (Kuang-che Wu)
Date: Mon, 11 May 2009 07:56:32 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
	line
Message-ID: <1242028592.51.0.619008752128.issue1759845@psf.upfronthosting.co.za>


Kuang-che Wu <kcwu at csie.org> added the comment:

ocrean-city's patch applied cleanly with trunk and it works for me.
Could anybody review and commit? I could help if any refinement required.

----------
nosy: +kcwu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Mon May 11 11:02:06 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 11 May 2009 09:02:06 +0000
Subject: [issue5804] Add an 'offset' argument to zlib.decompress
In-Reply-To: <1242032185.57.0.437214445534.issue5804@psf.upfronthosting.co.za>
Message-ID: <1242032517.8026.74.camel@lifeless-64>


Robert Collins <robertc at robertcollins.net> added the comment:

Well, I think its relatively uncommon to be doing such a loop with a
static buffer anyway - often you'll instead be reading from disk or a
network stream; if we could make those cases simpler and avoid copying
that would be great.

Anyhow, no strong opinions here, just saw it going by before added my
2c.

-Rob

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5804>
_______________________________________

From report at bugs.python.org  Mon May 11 12:08:05 2009
From: report at bugs.python.org (Ralph Corderoy)
Date: Mon, 11 May 2009 10:08:05 +0000
Subject: [issue5987] Broken link to "Curses Programming with Python"
In-Reply-To: <1241981621.95.0.54234756767.issue5987@psf.upfronthosting.co.za>
Message-ID: <1242036485.66.0.948881105112.issue5987@psf.upfronthosting.co.za>


Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk> added the comment:

Does that mean it's policy not to correct documentation for non-latest
versions?  Fair enough.  But perhaps
http://www.python.org/doc/2.5.2/lib/about.html should be changed to
reflect that, and likewise on other non-latest versions, e.g. "If the
problem still exists in the latest documentation, please report it".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5987>
_______________________________________

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: [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: [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 15:23:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 May 2009 13:23:54 +0000
Subject: [issue5995] unittest command line behaviour
In-Reply-To: <1242039588.66.0.255791822903.issue5995@psf.upfronthosting.co.za>
Message-ID: <1242048234.78.0.315327980086.issue5995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would be nice to have a test for the command line functionality but
I'm not sure it's easy.
In Misc/NEWS, please add the issue number as in other entries.
Other than that, looks fine.

----------
keywords:  -needs review
nosy: +pitrou
priority:  -> normal
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5995>
_______________________________________

From report at bugs.python.org  Mon May 11 15:27:01 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 May 2009 13:27:01 +0000
Subject: [issue5995] unittest command line behaviour
In-Reply-To: <1242039588.66.0.255791822903.issue5995@psf.upfronthosting.co.za>
Message-ID: <1242048421.25.0.342110470392.issue5995@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I didn't add the issue number because I created the patch prior to
creating the issue. Will add when I commit. Would like permission to
commit this from an interested core developer.

----------

_______________________________________
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: [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 16:18:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 May 2009 14:18:08 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1242007713.71.0.74563445658.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242051603.5368.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 2. The current WeakSet implementation returns True if a WeakSet is
> compared to any Iterable which contains the same set of objects:

Sounds bad. It should probably be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Mon May 11 16:56:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 May 2009 14:56:51 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1242053811.61.0.880600676497.issue5996@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also happens with other builtin types such as tuple. It's probably
related to the way subclasses of those types are instantiated, bypassing
the normal metaclass mechanism.

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Mon May 11 18:30:45 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 11 May 2009 16:30:45 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242059445.97.0.573237216982.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Sounds right to me. Here is another patch plus tests.

Going through the other tests, I adapted two more tests to actually test
WeakSet. Also, I found the following one and think it is a copy&paste
from test_set which is not useful for test_weakset. Should it be removed
(as currently done in the patch)?

def test_set_literal(self):
    s = set([1,2,3])
    t = {1,2,3}
    self.assertEqual(s, t)

----------
Added file: http://bugs.python.org/file13957/_weakrefset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Mon May 11 18:30:56 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 11 May 2009 16:30:56 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242059456.12.0.464448275497.issue5964@psf.upfronthosting.co.za>


Changes by Robert Schuppenies <robert.schuppenies at gmail.com>:


Removed file: http://bugs.python.org/file13955/_weakrefset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Mon May 11 18:33:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 May 2009 16:33:33 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1242059445.97.0.573237216982.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242059729.5548.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Going through the other tests, I adapted two more tests to actually test
> WeakSet. Also, I found the following one and think it is a copy&paste
> from test_set which is not useful for test_weakset. Should it be removed
> (as currently done in the patch)?

Absolutely!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Mon May 11 18:47:15 2009
From: report at bugs.python.org (Christopher Altona)
Date: Mon, 11 May 2009 16:47:15 +0000
Subject: [issue2708] IDLE subprocess error
In-Reply-To: <1209391841.34.0.293801648559.issue2708@psf.upfronthosting.co.za>
Message-ID: <1242060435.2.0.188929961375.issue2708@psf.upfronthosting.co.za>


Christopher Altona <caltona1 at gmail.com> added the comment:

I found that if I go into the Windows Task Manager and end (somtimes 
both of) the Python processes, the program will run properly the next 
time I open it.
Hope this helps.

----------
nosy: +ChrisAltona

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2708>
_______________________________________

From report at bugs.python.org  Mon May 11 19:26:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 May 2009 17:26:27 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
	line
Message-ID: <1242062787.3.0.044281958499.issue1759845@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The first patch will introduce regressions for strings that cannot be
decoded with the filesystem encoding. It is necessary to provide a
fallback to the CreateProcessA function.

I'd prefer the python-only patch, except for the "sys=sys" argument to
the function. Is it really needed?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Mon May 11 19:33:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 May 2009 17:33:36 +0000
Subject: [issue5981] float.fromhex bugs
In-Reply-To: <1241898617.16.0.557804357136.issue5981@psf.upfronthosting.co.za>
Message-ID: <1242063216.86.0.726070219167.issue5981@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r72564 (trunk), r72565 (py3k).  The trailing whitespace bugfix 
was backported in r72566 (2.6) and r72567 (3.0), but those versions still 
use locale-aware isspace and islower.

As a semi-accidental by-product, the fix also changes the behaviour of 
float.fromhex('-nan'): previously, float.fromhex('-nan') and 
float.fromhex('nan') had the same sign;  now they have opposite signs. Sane code that's affected by the sign bit of a nan should be extremely 
rare, so I don't think this change is going to bother anyone.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5981>
_______________________________________

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: [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 20:00:11 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 May 2009 18:00:11 +0000
Subject: [issue5995] unittest command line behaviour
In-Reply-To: <1242039588.66.0.255791822903.issue5995@psf.upfronthosting.co.za>
Message-ID: <1242064811.03.0.713727398217.issue5995@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 72570.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5995>
_______________________________________

From report at bugs.python.org  Mon May 11 21:52:43 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 May 2009 19:52:43 +0000
Subject: [issue5997] strftime is broken
In-Reply-To: <1242064707.21.0.409196088491.issue5997@psf.upfronthosting.co.za>
Message-ID: <1242071563.82.0.883505745921.issue5997@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please read

http://docs.python.org/library/locale.html

specifically the docs for 'setlocale'. Before you call setlocale,
python's locale is 'C', just like for any C program before it calls
setlocale.

Python 2.6.2 (r262:71600, May  2 2009, 15:06:57) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> import time
>>> time.strftime("%x")
'05/11/09'
>>> locale.setlocale(locale.LC_ALL,"")
'tr_TR.utf-8'
>>> time.strftime("%x")
'11-05-2009'

----------
nosy: +r.david.murray
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5997>
_______________________________________

From report at bugs.python.org  Mon May 11 22:36:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2009 20:36:28 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242074188.69.0.142014886329.issue5945@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Mon May 11 22:37:57 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2009 20:37:57 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1242074277.21.0.578086385483.issue5982@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

From report at bugs.python.org  Mon May 11 22:39:18 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2009 20:39:18 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1242074358.04.0.439444106053.issue5953@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From report at bugs.python.org  Mon May 11 22:40:57 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2009 20:40:57 +0000
Subject: [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1242074457.0.0.902499488163.issue3292@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3292>
_______________________________________

From report at bugs.python.org  Mon May 11 22:47:16 2009
From: report at bugs.python.org (Jonathan Hayward)
Date: Mon, 11 May 2009 20:47:16 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1242074836.0.0.301258335649.issue5238@psf.upfronthosting.co.za>


Jonathan Hayward <jonathan.hayward at pobox.com> added the comment:

Constantine Sapuntzakis wrote:
> import ssl
> 
> # Work around python bug #5328
> def SSLSocket_makefile_fixed(self, mode='r', bufsize=-1):
>     from socket import _fileobject
> 
>     self._makefile_refs += 1
>     return _fileobject(self, mode, bufsize, True)
> 
> ssl.SSLSocket.makefile = SSLSocket_makefile_fixed

Is it possible this workaround has a bug?

In my production code the socket remains open both after this
monkeypatch and after manually closing the underlying socket. In the
attached test case (TLS certificate and keyfile referenced but not
included), a server does the following:

1: listens to a single HTTPS request on port 8443.
2: Serves a "Hello, world!" page.
3: Closes the connection.
4: Sleeps for five seconds.
5: Exits the process.

The server incorporates the quoted patch, and the behavior from within
Firefox is that it serves up a "Hello world!" page via
https://localhost:8443/ and the connection remains open for five seconds
until the server process exits, apparently indicating a connection that
remains open as long as the process is running.

Closing the underlying connection manually seems to work.

----------
Added file: http://bugs.python.org/file13958/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Mon May 11 23:06:10 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Mon, 11 May 2009 21:06:10 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242075970.83.0.951120147823.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

A solution for this issue could be to replace the setAttribute method as
follow:
- d["value"] = d["nodeValue"] = value
+ d["value"] = d["nodeValue"] = value.replace('\n',' ')

NOTE: I didn't do a patch, because I don't know which python version you
are using.

Please try this solution and give me a feedback, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

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: [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: [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:25:58 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Mon, 11 May 2009 21:25:58 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242077158.01.0.574399743829.issue5752@psf.upfronthosting.co.za>


Changes by Francesco Sechi <francesco.sechi at iet.unipi.it>:


Removed file: http://bugs.python.org/file13837/test_toxml.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Mon May 11 23:27:13 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Mon, 11 May 2009 21:27:13 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242077233.94.0.465198890869.issue5752@psf.upfronthosting.co.za>


Changes by Francesco Sechi <francesco.sechi at iet.unipi.it>:


Added file: http://bugs.python.org/file13960/test_toxml.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

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: [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:30:33 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Mon, 11 May 2009 21:30:33 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242077433.36.0.536775890795.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

I have uploaded a test script that shows that, without my patch, the
methods setAttribute and parseString work differently; adding my patch,
the behaviour is symmetric.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Mon May 11 23:40:43 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 May 2009 21:40:43 +0000
Subject: [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  Mon May 11 23:48:41 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 May 2009 21:48:41 +0000
Subject: [issue5846] Deprecate obsolete functions in unittest
In-Reply-To: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za>
Message-ID: <1242078521.51.0.0301194915975.issue5846@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hehe - I wasn't actually doing that, just replacing the use of the
obsolete functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5846>
_______________________________________

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: [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 00:35:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 May 2009 22:35:19 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1242081319.63.0.475990617005.issue5596@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +test_urlllib2_localnet DigestAuthHandler leaks nonces

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Tue May 12 00:35:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 May 2009 22:35:31 +0000
Subject: [issue6002] test_urllib2_localnet DigestAuthHandler leaks nonces
In-Reply-To: <1242081235.08.0.896974873294.issue6002@psf.upfronthosting.co.za>
Message-ID: <1242081331.05.0.0878411145403.issue6002@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: test_urlllib2_localnet DigestAuthHandler leaks nonces -> test_urllib2_localnet DigestAuthHandler leaks nonces

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6002>
_______________________________________

From report at bugs.python.org  Tue May 12 00:52:19 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 11 May 2009 22:52:19 +0000
Subject: [issue5997] strftime is broken
In-Reply-To: <1242064707.21.0.409196088491.issue5997@psf.upfronthosting.co.za>
Message-ID: <1242082339.77.0.62144844212.issue5997@psf.upfronthosting.co.za>


Jonathan <jonathan.cervidae at gmail.com> added the comment:

Works perfectly now, thank you and sorry for the inaccurate report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5997>
_______________________________________

From report at bugs.python.org  Tue May 12 01:06:58 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 11 May 2009 23:06:58 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1242083218.56.0.855610166187.issue5201@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

The updated patch inserts the single $ when needed.  I've checked this
on compiling python, stdlib extension modules and custom extension
modules and this gives the correct results in all cases.

----------
Added file: http://bugs.python.org/file13962/makevars2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5201>
_______________________________________

From report at bugs.python.org  Tue May 12 01:45:10 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Mon, 11 May 2009 23:45:10 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1242085510.52.0.206803652492.issue5238@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

I think there are two bugs spotted here. The first is the mentioned
missing "close" param to _fileobject in makefile() method.

The second one was noticed by Jonathan. He doesn't use makefile() at
all, yet his socket isn't closed either. Here's what I think is going on:

The raw filesystem socket seems to be closed only upon garbage
collection, when reference count of socket._realsocket drops to zero
(ie. it's not closed explicitly anywhere). _realsocket is wrapped by
socket._socketobject and all its close() method does is dropping
reference to _realsocket object it wraps.

The bug goes like this:
1. plain = socket.create_connection(...)
   it creates and wraps a native _realsocket (plain._sock) with
reference count = 1; "plain" is an instance of _socketobject
2. secure = ssl.wrap_socket(plain)
   because SSLSocket inherits from _socketobject, it also wraps
_realsocket plain._sock and the reference count is 2 now
3. secure.close()
   it calls in turn it's parent method close() which simply drops raw
_realsocket reference count to 1
4. native socket is still referenced by plain._sock and filesystem
descriptor isn't closed unless plain.close() is called too and refcount
drops to zero

I attach the simplest possible test to prove the bug.

----------
nosy: +marcin.bachry
Added file: http://bugs.python.org/file13963/test-simple.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Tue May 12 02:41:09 2009
From: report at bugs.python.org (Greg Couch)
Date: Tue, 12 May 2009 00:41:09 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
	line
Message-ID: <1242088869.89.0.989406417417.issue1759845@psf.upfronthosting.co.za>


Greg Couch <gregc at cgl.ucsf.edu> added the comment:

I like the C patch better.  It only tries to decode non-unicode objects
with the filesystem (mbcs) encoding.  This fits in with Python 3.0
perfectly where all strings are unicode.  In 2.5, strings are assumed to
be in the mbcs encoding, to match the Windows ANSI API, so decoding
those with the mbcs encoding shouldn't alter the set of acceptable
strings (which is what the C patch is doing if I read the code correctly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Tue May 12 03:01:03 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 01:01:03 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1242090063.99.0.672794704102.issue4066@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Thanks, Marcin!

Same bug seems to apply to py3k, ported patches attached.

----------
stage:  -> patch review
versions: +Python 3.1
Added file: http://bugs.python.org/file13964/return_socket.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Tue May 12 03:14:19 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 May 2009 01:14:19 +0000
Subject: [issue5265] StringIO can duplicate newlines in universal newlines mode
In-Reply-To: <1234650978.85.0.656093494146.issue5265@psf.upfronthosting.co.za>
Message-ID: <1242090859.72.0.687175620721.issue5265@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Although this was fixed for 3.1, it appears not to be fixed for Python
2.6 or 2.7.

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
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> io.StringIO('foo\r\nbar\r\n', newline=None).read()
u'foo\n\nbar\n\n'

Note that this behavior is slightly different from what pitrou reported.

If this cannot be fixed in 2.6, the documentation should at least
reflect that it doesn't work until a later version.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5265>
_______________________________________

From report at bugs.python.org  Tue May 12 03:22:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 May 2009 01:22:29 +0000
Subject: [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: <1242091349.37.0.584304699144.issue5994@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch attached for trunk based on 2.6.2 docs.  I only included what felt
like the essential parts of the module description.

----------
assignee: georg.brandl -> r.david.murray
keywords: +patch
nosy: +r.david.murray
stage:  -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file13965/issue5994.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5994>
_______________________________________

From report at bugs.python.org  Tue May 12 03:42:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 May 2009 01:42:48 +0000
Subject: [issue5957] Possible mistake regarding writeback in documentation of
	shelve.open()
In-Reply-To: <1241719241.22.0.336086356581.issue5957@psf.upfronthosting.co.za>
Message-ID: <1242092568.67.0.99047299808.issue5957@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r72572, r72573, r72574, and r72575.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5957>
_______________________________________

From report at bugs.python.org  Tue May 12 04:09:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 May 2009 02:09:59 +0000
Subject: [issue1584] Mac OS X: building with X11 Tkinter
In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>
Message-ID: <1242094199.72.0.67096147207.issue1584@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1584>
_______________________________________

From report at bugs.python.org  Tue May 12 05:10:49 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 12 May 2009 03:10:49 +0000
Subject: [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: <1242097849.34.0.246398734922.issue5994@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

David, should the marshal.version be explained as it is present in the docs?

marshal.version

    Indicates the format that the module uses. Version 0 is the
historical format, version 1 (added in Python 2.4) shares interned
strings and version 2 (added in Python 2.5) uses a binary format for
floating point numbers. The current version is 2.

Otherwise, the patch is fine and can be applied. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5994>
_______________________________________

From report at bugs.python.org  Tue May 12 05:22:51 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 12 May 2009 03:22:51 +0000
Subject: [issue5265] StringIO can duplicate newlines in universal newlines mode
In-Reply-To: <1234650978.85.0.656093494146.issue5265@psf.upfronthosting.co.za>
Message-ID: <1242098571.11.0.483604198889.issue5265@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The bug shouldn't affect 2.6 and 2.7 unless you backported the now
obsolete _stringio module from 3.0.

I tested 2.6 and 2.7 and as expected I didn't see the bug:

Python 2.6.2+ (release26-maint:72576, May 11 2009, 23:16:48) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> io.StringIO('foo\r\nbar\r\n', newline=None).read()
u'foo\nbar\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5265>
_______________________________________

From report at bugs.python.org  Tue May 12 05:29:31 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 03:29:31 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242098971.04.0.0259931097976.issue5752@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Francesco,
Your patch still doesn't allow one to add a multiline attribute values
as Tomalak describes:
"The catch: This leads to an actual data loss if I *wanted* to store
newline characters in an attribute -- unless the newline characters are
properly encoded. Encoding the newline characters is also valid and
conforms to the spec, so the DOM implementation should do it."

I'm not sure whether the proposed behavior is correct or desirable. Even
if it is correct, it might introduce backwards incompatible changes in
behavior.

Here's a test case for trunk.

----------
nosy: +ajaksu2
Added file: http://bugs.python.org/file13966/test_multiline_roundtrip.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Tue May 12 05:30:07 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 03:30:07 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242099007.78.0.639338180426.issue5752@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Tue May 12 05:33:22 2009
From: report at bugs.python.org (Kuang-che Wu)
Date: Tue, 12 May 2009 03:33:22 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
	line
Message-ID: <1242099202.46.0.120852396783.issue1759845@psf.upfronthosting.co.za>


Kuang-che Wu <kcwu at csie.org> added the comment:

There is slight difference between C and python patch.
C version: convert mbcs argument to unicode
py version: convert unicode argument to mbcs

Actually, python version patch may not work if the string is unicode and
cannot encoded by mbcs. For example, my windows system is Chinese
(cp950) and the program I want to execute contains Japanese characters.
Encode Japanese characters with mbcs (in this case, it is cp950) will
fail. This is also what Matt (mclausch) said.

On the other hand, the C version patch. I don't think fall-back is
necessary. If the string is failed to convert from mbcs to unicode, it
will be eventually failed inside CreateProcessA() because CreateProcessA
internally (after win2k) will try to convert from mbcs to unicode and
call CreateProcessW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Tue May 12 06:03:05 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 04:03:05 +0000
Subject: [issue2813] No float formatting in PyString_FromFormat
In-Reply-To: <1210453747.33.0.971608840544.issue2813@psf.upfronthosting.co.za>
Message-ID: <1242100985.66.0.675646283501.issue2813@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +eric.smith
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2813>
_______________________________________

From report at bugs.python.org  Tue May 12 07:03:23 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 05:03:23 +0000
Subject: [issue1672568] silent error in email.message.Message.get_payload
Message-ID: <1242104602.63.0.0793522919004.issue1672568@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Renaud,
Here's your patch with a test case against trunk.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file13967/noisy_get_payload.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672568>
_______________________________________

From report at bugs.python.org  Tue May 12 08:09:30 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 06:09:30 +0000
Subject: [issue1741130] struct.pack("I", "foo");
	struct.pack("L", "foo") should fail
Message-ID: <1242108570.13.0.237337932889.issue1741130@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Mark, Virgil: Thanks for correcting my wrong assessment!

The lucky TypeError comes from rev 68120.

It looks like that error message in trunk is due to a "PyNumber_And(v,
pylong_ulong_mask)" when v isn't a PyNumber. I've added a "get_pylong(v)
== NULL" check in the attached patch, but my C is weak :)

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file13968/fail_pack_non_int.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1741130>
_______________________________________

From report at bugs.python.org  Tue May 12 08:47:00 2009
From: report at bugs.python.org (Supreet)
Date: Tue, 12 May 2009 06:47:00 +0000
Subject: [issue4540] typo in a module describes utf-8 as uft-8
In-Reply-To: <1228433923.53.0.179522089961.issue4540@psf.upfronthosting.co.za>
Message-ID: <1242110820.96.0.587610961826.issue4540@psf.upfronthosting.co.za>


Supreet <supreet.sethi at gmail.com> added the comment:

I faced similar issue. The solution is either to add tests as an
exception in pydoc or to move tests to /usr/share or /usr/share/doc.

I favor the second solution

----------
nosy: +djinn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4540>
_______________________________________

From report at bugs.python.org  Tue May 12 10:26:35 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Tue, 12 May 2009 08:26:35 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242116795.88.0.829658569015.issue5752@psf.upfronthosting.co.za>


Francesco Sechi <francesco.sechi at iet.unipi.it> added the comment:

My position is: 
if you want to encode the newline character, this should be done by both
parseString and setAttribute methods. Otherwise, the behaviour is not
symmetric.
My patch translates the newline character with a whitespace in the
setAttribute method, because parseString already does it. If you want to
encode the newline in different manner, you should develop a patch that
introduces this kind of encoding in both parseString and setAttribute
methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

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: [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:51 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 May 2009 09:36:51 +0000
Subject: [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 11:43:42 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 May 2009 09:43:42 +0000
Subject: [issue6004] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121010.51.0.200108534181.issue6004@psf.upfronthosting.co.za>
Message-ID: <1242121422.04.0.491819548999.issue6004@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Too impatient while submitting the report...

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6004>
_______________________________________

From report at bugs.python.org  Tue May 12 12:50:47 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 12 May 2009 10:50:47 +0000
Subject: [issue5995] unittest command line behaviour
In-Reply-To: <1242039588.66.0.255791822903.issue5995@psf.upfronthosting.co.za>
Message-ID: <1242125447.08.0.852841632153.issue5995@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This commit caused a regression in command line behavior of modules
using unittest.main(). Fixed in revision 72583.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5995>
_______________________________________

From report at bugs.python.org  Tue May 12 13:28:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 11:28:19 +0000
Subject: [issue1143] Update to latest ElementTree in Python 2.7
In-Reply-To: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za>
Message-ID: <1242127699.21.0.272842654052.issue1143@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fredrik, will this be able to go in before 3.1rc1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1143>
_______________________________________

From report at bugs.python.org  Tue May 12 14:25:15 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 12 May 2009 12:25:15 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1242131115.45.0.350876724605.issue6001@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The usage information in TestProgram in this patch is not correct. 

If __name__ != __main__ it should be unchanged - the new usage message
should only be displayed if unittest is run as __main__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

From report at bugs.python.org  Tue May 12 14:26:37 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 12 May 2009 12:26:37 +0000
Subject: [issue2813] No float formatting in PyString_FromFormat
In-Reply-To: <1210453747.33.0.971608840544.issue2813@psf.upfronthosting.co.za>
Message-ID: <1242131197.14.0.262941682748.issue2813@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

>From the code:

/* assume %f produces at most (L)DBL_DIG 
   digits before and after the decimal
   point, plus the latter plus a sign */

This is not correct. DBL_DIG is 15 on my x86 Linux machine.    
printf("%.*f\n", DBL_DIG, 1e20) produces a string that's 37 characters
long. It might be best to use PyOS_double_to_string instead of snprintf,
although we don't support long double there. I'm not sure long double
support is all that important in practice (for Python), though.

It would be easier to review this if the %p change weren't also
included. That's looks like a good change, but it's a separate issue.

unicodeobject.c should also be modified. In 3.x, it's unicodeobject.c
and bytesobject.c that need to work.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2813>
_______________________________________

From report at bugs.python.org  Tue May 12 14:29:26 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 12 May 2009 12:29:26 +0000
Subject: [issue1207] Load tests from path (patch included)
In-Reply-To: <1190834704.12.0.956914269209.issue1207@psf.upfronthosting.co.za>
Message-ID: <1242131366.75.0.700602266024.issue1207@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

See issue 6001 for a patch implementing test discovery for unittest.

It would allow you to do:

    python -m unittest discover

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207>
_______________________________________

From report at bugs.python.org  Tue May 12 14:42:00 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:42:00 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1242132120.54.0.113058788233.issue1513299@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Tue May 12 14:43:50 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:43:50 +0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1242132230.78.0.0359503693846.issue2118@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.1 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
_______________________________________

From report at bugs.python.org  Tue May 12 14:46:34 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:46:34 +0000
Subject: [issue1569291] Speed-up in array_repeat()
Message-ID: <1242132394.03.0.552688359629.issue1569291@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569291>
_______________________________________

From report at bugs.python.org  Tue May 12 14:47:12 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:47:12 +0000
Subject: [issue2958] update Lib/test/README
In-Reply-To: <1211637344.19.0.700206389482.issue2958@psf.upfronthosting.co.za>
Message-ID: <1242132432.18.0.479141835741.issue2958@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +michael.foord
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2958>
_______________________________________

From report at bugs.python.org  Tue May 12 14:49:26 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:49:26 +0000
Subject: [issue1057417] New BaseSMTPServer module
Message-ID: <1242132566.38.0.509527466262.issue1057417@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1057417>
_______________________________________

From report at bugs.python.org  Tue May 12 14:50:59 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:50:59 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1242132659.46.0.291490103722.issue2768@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +benjamin.peterson, pitrou
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Tue May 12 14:53:11 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 12:53:11 +0000
Subject: [issue2856] os.listdir doc should mention that Unicode decoding can
	fail
In-Reply-To: <1210814208.45.0.272157928062.issue2856@psf.upfronthosting.co.za>
Message-ID: <1242132791.63.0.764577696125.issue2856@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Library (Lib), Unicode
nosy: +haypo, loewis
priority:  -> normal
versions: +Python 2.6, Python 3.1 -Python 2.3, Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2856>
_______________________________________

From report at bugs.python.org  Tue May 12 15:06:47 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:06:47 +0000
Subject: [issue1724366] cPickle module doesn't work with universal line endings
Message-ID: <1242133607.71.0.913197172694.issue1724366@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk and py3k.

----------
components: +IO
nosy: +ajaksu2, benjamin.peterson, pitrou
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 3.1 -Python 2.4
Added file: http://bugs.python.org/file13969/pickletest_py3k.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724366>
_______________________________________

From report at bugs.python.org  Tue May 12 15:07:44 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 May 2009 13:07:44 +0000
Subject: [issue5265] StringIO can duplicate newlines in universal newlines mode
In-Reply-To: <1242098571.11.0.483604198889.issue5265@psf.upfronthosting.co.za>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B674F4908CEE@hornigold.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Perhaps I was wrong about 2.7.  However, I'm using stock builds of Python 2.6.2 for Windows, both 32- and 64-bit, and I get the undesirable behavior.  Apparently the problem is platform-specific.  Should this issue go under a new ticket?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5265>
_______________________________________

From report at bugs.python.org  Tue May 12 15:09:10 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:09:10 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1242133750.61.0.911212691621.issue2661@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Tests
priority:  -> normal
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
_______________________________________

From report at bugs.python.org  Tue May 12 15:17:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:17:20 +0000
Subject: [issue1724366] cPickle module doesn't work with universal line endings
Message-ID: <1242134240.48.0.529137128965.issue1724366@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why would use a file in universal line endings mode for saving/loading
pickles? Pickles are binary data (even if version 0 pickles happens to
be human-readable), so you should open the files in binary mode (either
"rb" or "wb").

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724366>
_______________________________________

From report at bugs.python.org  Tue May 12 15:20:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:20:15 +0000
Subject: [issue1724366] cPickle module doesn't work with universal line endings
Message-ID: <1242134415.16.0.813386637656.issue1724366@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also, I don't understand how you confirmed this bug under py3k. Text
files under py3k forbid bytes input, which is what pickle produces:

>>> pickle.dump([], sys.stdout)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/pickle.py", line 1333, in dump
    Pickler(file, protocol).dump(obj)
TypeError: write() argument 1 must be str, not bytes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724366>
_______________________________________

From report at bugs.python.org  Tue May 12 15:20:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:20:54 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1242134454.49.0.206728056167.issue2768@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please produce a single patch comprising all changes. Also, there seem
to be some misindentations in the modified C code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Tue May 12 15:22:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:22:08 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1242134528.12.0.735622900473.issue2661@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
_______________________________________

From report at bugs.python.org  Tue May 12 15:23:19 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:23:19 +0000
Subject: [issue1511] csv input converts \r\n to \n but csv output does not
	when a field has internal line breaks
In-Reply-To: <1196226917.03.0.0879630569127.issue1511@psf.upfronthosting.co.za>
Message-ID: <1242134599.0.0.550465587772.issue1511@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I get different behavior in py3k compared to trunk:

~/trunk-py$ ./python issue1511_py3k.py
[['foo', 'bar\r\nbaz\r\nbiff', 'boo']]
'foo,"bar\r\nbaz\r\nbiff",boo\r\n'

~/trunk-py$ ../py3k/python issue1511_py3k.py
[['foo', 'bar\nbaz\nbiff', 'boo']]
'foo,"bar\nbaz\nbiff",boo\n'

----------
components: +IO
nosy: +ajaksu2, pitrou
stage:  -> test needed
versions: +Python 2.6 -Python 2.4
Added file: http://bugs.python.org/file13970/issue1511_py3k.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1511>
_______________________________________

From report at bugs.python.org  Tue May 12 15:24:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:24:28 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1242134668.62.0.402410918207.issue6003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This sounds like a good idea. Can you provide a patch (including tests)?

----------
assignee:  -> ronaldoussoren
components: +Library (Lib)
nosy: +pitrou
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6003>
_______________________________________

From report at bugs.python.org  Tue May 12 15:25:55 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:25:55 +0000
Subject: [issue1672853] Error reading files larger than 4GB
Message-ID: <1242134755.38.0.836378395949.issue1672853@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +IO
nosy: +benjamin.peterson, pitrou
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672853>
_______________________________________

From report at bugs.python.org  Tue May 12 15:26:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:26:39 +0000
Subject: [issue2958] update Lib/test/README
In-Reply-To: <1211637344.19.0.700206389482.issue2958@psf.upfronthosting.co.za>
Message-ID: <1242134799.83.0.660807202584.issue2958@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The README was so outdated that apparently it isn't in SVN anymore...

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2958>
_______________________________________

From report at bugs.python.org  Tue May 12 15:27:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:27:23 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242134843.9.0.452381541706.issue5945@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue May 12 15:28:06 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:28:06 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242134886.72.0.848042963233.issue1621@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +haypo
stage:  -> patch review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue May 12 15:29:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:29:05 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242134945.91.0.46149862736.issue1621@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue May 12 15:29:27 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:29:27 +0000
Subject: [issue1554] socketmodule cleanups: allow the use of keywords in
	socket functions
In-Reply-To: <1196784173.07.0.425557098914.issue1554@psf.upfronthosting.co.za>
Message-ID: <1242134967.19.0.499589292393.issue1554@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1554>
_______________________________________

From report at bugs.python.org  Tue May 12 15:30:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 May 2009 13:30:16 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1242135016.03.0.583441734418.issue6003@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I will.

I guess it's too late to merge this into 3.1 (as the first beta has 
already been released).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6003>
_______________________________________

From report at bugs.python.org  Tue May 12 15:30:39 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 13:30:39 +0000
Subject: [issue1142] code sample showing errors reading large files with py
	2.5/3.0
In-Reply-To: <1189439562.54.0.204300359031.issue1142@psf.upfronthosting.co.za>
Message-ID: <1242135039.15.0.441308317047.issue1142@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +IO
nosy: +benjamin.peterson, pitrou
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1142>
_______________________________________

From report at bugs.python.org  Tue May 12 15:31:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:31:14 +0000
Subject: [issue2856] os.listdir doc should mention that Unicode decoding can
	fail
In-Reply-To: <1210814208.45.0.272157928062.issue2856@psf.upfronthosting.co.za>
Message-ID: <1242135074.55.0.0490543833571.issue2856@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it about 2.6 or 3.0/3.1? This problem should have been solved in 3.1,
by the way of special escaping for undecodable characters (that is,
os.listdir() will always return strings rather than bytes objects, but
some of those strings may have special escapes in them).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2856>
_______________________________________

From report at bugs.python.org  Tue May 12 15:33:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:33:23 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1242135203.99.0.207781437976.issue6003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I guess it's too late to merge this into 3.1 (as the first beta has 
> already been released).

Since the change should be small and uncontroversial, I think it could
go in.
Benjamin has the final word.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6003>
_______________________________________

From report at bugs.python.org  Tue May 12 15:44:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 13:44:51 +0000
Subject: [issue6000] compile error - PyNumber_InPlaceOr(newfree, allfree) < 0
In-Reply-To: <1242077376.02.0.0771878872904.issue6000@psf.upfronthosting.co.za>
Message-ID: <1242135891.43.0.334930232455.issue6000@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, PyNumber_InPlaceOr() returns a PyObject*, no wonder why the
compiler complains.
I suppose gcc and MSVC and /really/ laxist to let this error fall through.

----------
keywords: +easy
nosy: +pitrou
priority:  -> critical
stage:  -> needs patch
title: compile error on AIX and HP-UX 11.00 - PyNumber_InPlaceOr(newfree, allfree) < 0 -> compile error - PyNumber_InPlaceOr(newfree, allfree) < 0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6000>
_______________________________________

From report at bugs.python.org  Tue May 12 15:59:34 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 12 May 2009 13:59:34 +0000
Subject: [issue1511] csv input converts \r\n to \n but csv output does not
	when a field has internal line breaks
In-Reply-To: <1242134599.0.0.550465587772.issue1511@psf.upfronthosting.co.za>
Message-ID: <18953.32961.415536.94534@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Daniel> Daniel Diniz <ajaksu at gmail.com> added the comment:

    Daniel> I get different behavior in py3k compared to trunk:

        Daniel> ~/trunk-py$ ./python issue1511_py3k.py
        Daniel> [['foo', 'bar\r\nbaz\r\nbiff', 'boo']]
        Daniel> 'foo,"bar\r\nbaz\r\nbiff",boo\r\n'

        Daniel> ~/trunk-py$ ../py3k/python issue1511_py3k.py
        Daniel> [['foo', 'bar\nbaz\nbiff', 'boo']]
        Daniel> 'foo,"bar\nbaz\nbiff",boo\n'

Try adding newline='' to your open calls.  I believe that will preserve the
CRLF pairs.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1511>
_______________________________________

From report at bugs.python.org  Tue May 12 16:08:02 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 14:08:02 +0000
Subject: [issue1511] csv input converts \r\n to \n but csv output does not
	when a field has internal line breaks
In-Reply-To: <1196226917.03.0.0879630569127.issue1511@psf.upfronthosting.co.za>
Message-ID: <1242137282.42.0.213138645841.issue1511@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

You're right, sorry about the noise. Closing as out of date.

----------
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1511>
_______________________________________

From report at bugs.python.org  Tue May 12 16:09:32 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 14:09:32 +0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1242137372.5.0.245752136429.issue2142@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 3.1 -Python 2.3, Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Tue May 12 16:15:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 May 2009 14:15:44 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1242137744.45.0.608043578242.issue3061@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

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: [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 16:25:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 May 2009 14:25:39 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1242138339.53.0.0467066367251.issue2537@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2537>
_______________________________________

From report at bugs.python.org  Tue May 12 16:30:47 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 14:30:47 +0000
Subject: [issue4135] help("modules ftp") fails due to test modules
In-Reply-To: <1224194736.44.0.337868576776.issue4135@psf.upfronthosting.co.za>
Message-ID: <1242138647.65.0.762707831562.issue4135@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This is a duplicate of issue 4540.

----------
nosy: +ajaksu2
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> typo in a module describes utf-8 as uft-8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4135>
_______________________________________

From report at bugs.python.org  Tue May 12 16:32:41 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 14:32:41 +0000
Subject: [issue1705520] pyunit should allow __unittest in locals to trim
	stackframes
Message-ID: <1242138761.83.0.201333759996.issue1705520@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +michael.foord
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Tue May 12 16:41:55 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 May 2009 14:41:55 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1242139315.71.0.137777066248.issue1693050@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Tue May 12 16:44:45 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 12 May 2009 14:44:45 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1242139485.73.0.97864113109.issue4947@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

The matter had been discussed (and not once...), IMO without 
satisfactory conclusion -- see:

* http://bugs.python.org/issue612627 (the feature added)
* http://bugs.python.org/issue1214889 (another feature rejected)
* http://bugs.python.org/issue1099364 (problems reported)
* http://bugs.python.org/issue967986 (problems reported)
* http://mail.python.org/pipermail/python-list/2008-December/693601.html
* http://mail.python.org/pipermail/python-dev/2008-December/084362.html
* and probably in many other places...

Anyway, it's definitely a bug -- either in the language/implementation 
or in the documentation.

----------
nosy: +zuo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Tue May 12 16:46:01 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 12 May 2009 14:46:01 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1242139561.81.0.208524919998.issue5201@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

Oh, sorry about the super() that is why the ar test failed then.  Sorry,
I got a little confused by the conflicting update on that file while
working on this patch and must have merged it badly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5201>
_______________________________________

From report at bugs.python.org  Tue May 12 16:56:03 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 12 May 2009 14:56:03 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1242140163.71.0.8830290381.issue4947@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

PS. The main problem is not a lack of feature but that inconsistency, 
and that's not documented if File type docs:

print >>my_file, my_unicode  # <- is encoded with my_file.encoding
my_file.write(my_unicode)  # <- is encoded with my_file.encoding

# and on the other hand:
print my_unicode -- works  # <- is encoded with my_file.encoding
sys.stdout.write(my_unicode)  # <- is encoded with what is returned by 
sys.getdefaultencoding()

----------
versions: +Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Tue May 12 17:01:41 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 12 May 2009 15:01:41 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1242140501.1.0.424260110267.issue4947@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

s / if File / in File
s / -- works  # <- is encoded with my_file.encoding /  # <- is encoded 
with sys.stdout.encoding

(sorry, too little sleep)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Tue May 12 17:36:13 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 15:36:13 +0000
Subject: [issue1552] fromfd() and socketpair() should return wrapped sockets
In-Reply-To: <1196739495.6.0.25894007336.issue1552@psf.upfronthosting.co.za>
Message-ID: <1242142573.28.0.540648489416.issue1552@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552>
_______________________________________

From report at bugs.python.org  Tue May 12 17:53:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 May 2009 15:53:23 +0000
Subject: [issue6000] compile error - PyNumber_InPlaceOr(newfree, allfree) < 0
In-Reply-To: <1242077376.02.0.0771878872904.issue6000@psf.upfronthosting.co.za>
Message-ID: <1242143603.89.0.105077124968.issue6000@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The error's also in 3.0.

----------
nosy: +marketdickinson
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6000>
_______________________________________

From report at bugs.python.org  Tue May 12 18:14:35 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 16:14:35 +0000
Subject: [issue4050] inspect.findsource() returns binary data for shared
	library modules
In-Reply-To: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>
Message-ID: <1242144875.67.0.303949499094.issue4050@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This bug seems to break help(C-module) in py3k after rev 70587:

>>> import pickle
>>> help(pickle)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~/py3k/Lib/site.py", line 429, in __call__
    return pydoc.help(*args, **kwds)
  File "~/py3k/Lib/pydoc.py", line 1709, in __call__
    self.help(request)
  File "~/py3k/Lib/pydoc.py", line 1755, in help
    else: doc(request, 'Help on %s:')
  File "~/py3k/Lib/pydoc.py", line 1505, in doc
    pager(render_doc(thing, title, forceload))
  File "~/py3k/Lib/pydoc.py", line 1500, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "~/py3k/Lib/pydoc.py", line 320, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "~/py3k/Lib/pydoc.py", line 1086, in docmodule
    contents.append(self.document(value, key, name))
  File "~/py3k/Lib/pydoc.py", line 321, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "~/py3k/Lib/pydoc.py", line 1131, in docclass
    doc = getdoc(object)
  File "~/py3k/Lib/pydoc.py", line 81, in getdoc
    result = inspect.getdoc(object) or inspect.getcomments(object)
  File "~/py3k/Lib/inspect.py", line 581, in getcomments
    lines, lnum = findsource(object)
  File "~/py3k/Lib/inspect.py", line 524, in findsource
    lines = linecache.getlines(file, module.__dict__)
  File "~/py3k/Lib/linecache.py", line 41, in getlines
    return updatecache(filename, module_globals)
  File "~/py3k/Lib/linecache.py", line 130, in updatecache
    lines = fp.readlines()
  File "~/py3k/Lib/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 24:
unexpected code byte


brodierao's patch fixes it.

----------
nosy: +haypo
priority: normal -> release blocker
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4050>
_______________________________________

From report at bugs.python.org  Tue May 12 19:03:44 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:03:44 +0000
Subject: [issue821862] ftplib: Strict RFC 959 (telnet in command channel)
Message-ID: <1242147824.7.0.73632222893.issue821862@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 3.1 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue821862>
_______________________________________

From report at bugs.python.org  Tue May 12 19:04:25 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:04:25 +0000
Subject: [issue1576598] ftplib doesn't follow standard
Message-ID: <1242147865.46.0.120643951328.issue1576598@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +ftplib: Strict RFC 959 (telnet in command channel)
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1576598>
_______________________________________

From report at bugs.python.org  Tue May 12 19:05:12 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:05:12 +0000
Subject: [issue1574310] os.popen with os.close gives error message
Message-ID: <1242147912.42.0.311729707675.issue1574310@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574310>
_______________________________________

From report at bugs.python.org  Tue May 12 19:06:40 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:06:40 +0000
Subject: [issue1543469] test_subprocess fails on cygwin
Message-ID: <1242148000.02.0.389634292592.issue1543469@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
resolution:  -> wont fix
stage: test needed -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1543469>
_______________________________________

From report at bugs.python.org  Tue May 12 19:07:48 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:07:48 +0000
Subject: [issue1676121] Problem linking to readline lib on x86(64) Solaris
Message-ID: <1242148068.32.0.467763636206.issue1676121@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: pending -> closed
superseder:  -> documentation for new SSL module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676121>
_______________________________________

From report at bugs.python.org  Tue May 12 19:08:42 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:08:42 +0000
Subject: [issue831574] Solaris term.h needs curses.h
Message-ID: <1242148122.25.0.248922806967.issue831574@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Closing on lack of feedback.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue831574>
_______________________________________

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: [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 19:36:03 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:36:03 +0000
Subject: [issue1729930] 2.5.1 latest svn fails test_curses and test_timeout
Message-ID: <1242149763.9.0.0937975193195.issue1729930@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Tests
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729930>
_______________________________________

From report at bugs.python.org  Tue May 12 19:37:13 2009
From: report at bugs.python.org (Krzysztof Klimonda)
Date: Tue, 12 May 2009 17:37:13 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1242149833.06.0.0849368439818.issue3872@psf.upfronthosting.co.za>


Krzysztof Klimonda <kklimonda at syntaxhighlighted.com> added the comment:

I still get this error using "Python 2.6.2 (release26-maint, Apr 19
2009, 01:58:18)" on Ubuntu 9.04:
https://bugs.launchpad.net/bugs/371720
Also test_combotix.py doesn't work.

----------
nosy: +kklimonda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Tue May 12 19:48:05 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:48:05 +0000
Subject: [issue1260171] subprocess: more general (non-buffering) communication
Message-ID: <1242150485.88.0.362238371068.issue1260171@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
keywords: +patch
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1260171>
_______________________________________

From report at bugs.python.org  Tue May 12 19:52:28 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:52:28 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1242150748.29.0.265784748119.issue1195@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk, doesn't seem to affect py3k.

----------
keywords: +patch
nosy: +ajaksu2
stage:  -> test needed
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 12 19:54:36 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 17:54:36 +0000
Subject: [issue706392] faster _socket.connect variant desired
Message-ID: <1242150876.79.0.975577465396.issue706392@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706392>
_______________________________________

From report at bugs.python.org  Tue May 12 20:04:46 2009
From: report at bugs.python.org (Krzysztof Klimonda)
Date: Tue, 12 May 2009 18:04:46 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1242151486.46.0.0733662860655.issue3872@psf.upfronthosting.co.za>


Krzysztof Klimonda <kklimonda at syntaxhighlighted.com> added the comment:

It is probably related to the old version of Tix that both Debian and
Ubuntu ship.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Tue May 12 20:04:59 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 18:04:59 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1242151499.53.0.578932963058.issue706406@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6
Added file: http://bugs.python.org/file13971/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Tue May 12 20:07:12 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 18:07:12 +0000
Subject: [issue730473] Add Py_AtInit() startup hook for extenders
Message-ID: <1242151632.81.0.488111295381.issue730473@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730473>
_______________________________________

From report at bugs.python.org  Tue May 12 20:11:44 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 May 2009 18:11:44 +0000
Subject: [issue6000] compile error - PyNumber_InPlaceOr(newfree, allfree) < 0
In-Reply-To: <1242077376.02.0.0771878872904.issue6000@psf.upfronthosting.co.za>
Message-ID: <1242151904.54.0.728846147709.issue6000@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6000>
_______________________________________

From report at bugs.python.org  Tue May 12 20:25:21 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 May 2009 18:25:21 +0000
Subject: [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: <1242152721.27.0.360110812813.issue5999@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Adding Martin to the nosy list as this is related to his change:
http://svn.python.org/view/python/branches/py3k/Modules/python.c?view=annotate#l17

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Tue May 12 20:29:10 2009
From: report at bugs.python.org (Michael Stone)
Date: Tue, 12 May 2009 18:29:10 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1242152950.12.0.759249624546.issue706406@psf.upfronthosting.co.za>


Michael Stone <mbrierst at gmail.com> added the comment:

ajaksu2 has uploaded a file called "test.py" that seems to have nothing 
to do with this issue, unless I'm misunderstanding something.  I don't 
see any call to readline in the uploaded file at all.  Perhaps the file 
you meant to upload, was the one from issue 1113?
http://bugs.python.org/file8392/test.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Tue May 12 20:29:38 2009
From: report at bugs.python.org (Michael Stone)
Date: Tue, 12 May 2009 18:29:38 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1242152978.35.0.0921957560604.issue706406@psf.upfronthosting.co.za>


Changes by Michael Stone <mbrierst at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Tue May 12 20:33:42 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 18:33:42 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1242153222.03.0.905028325549.issue706406@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Removed file: http://bugs.python.org/file13971/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Tue May 12 20:36:16 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 18:36:16 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1242153376.98.0.713961035379.issue706406@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Oops, sorry! I should know better than to name scripts test.py: the
upload failed and when I realized that (after some time), test.py was
already something else.

Thanks for catching this instance of PEBKAC, Michael :)

----------
Added file: http://bugs.python.org/file13972/test_raw_input_signal.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Tue May 12 20:46:10 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 18:46:10 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242153970.18.0.280625005176.issue5977@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Tarek,
It looks like all buildbots are red because setup.py doesn't work with
this change:

running build
running build_ext
Traceback (most recent call last):
  File "./setup.py", line 1896, in <module>
    main()
  File "./setup.py", line 1891, in main
    'Lib/smtpd.py']
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/dist.py",
line 974, in run_commands
    self.run_command(cmd)
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/command/build.py",
line 132, in run
    self.run_command(cmd_name)
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/cmd.py",
line 326, in run_command
    self.distribution.run_command(command)
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/home2/buildbot/slave/trunk.loewis-sun/build/Lib/distutils/command/build_ext.py",
line 348, in run
    self.build_extensions()
  File "./setup.py", line 103, in build_extensions
    missing = self.detect_modules()
  File "./setup.py", line 302, in detect_modules
    add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
AttributeError: 'NoneType' object has no attribute 'library_dirs'
[31295 refs]
*** Error code 1
The following command caused the error:
case $MAKEFLAGS in \
*s*)  CC='gcc' LDSHARED='gcc -shared' OPT='-g -Wall -Wstrict-prototypes'
./python -E ./setup.py -q build;; \
*)  CC='gcc' LDSHARED='gcc -shared' OPT='-g -Wall -Wstrict-prototypes'
./python -E ./setup.py build;; \
esac
make: Fatal error: Command failed for target `sharedmods'
program finished with exit code 1

----------
nosy: +ajaksu2
priority:  -> critical
status: closed -> open
Added file: http://bugs.python.org/file13973/build_ext._compiler.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From report at bugs.python.org  Tue May 12 21:02:33 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 12 May 2009 19:02:33 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1242154953.15.0.882414513869.issue6001@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

From report at bugs.python.org  Tue May 12 21:03:04 2009
From: report at bugs.python.org (Dave Baggett)
Date: Tue, 12 May 2009 19:03:04 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1242154984.8.0.353201847551.issue917120@psf.upfronthosting.co.za>


Dave Baggett <jython at baggett.org> added the comment:

I'm not sure this causes the behavior reported here, but I believe there
really is a bug in imaplib.

In particular, it seems wrong to me that this line:

mustquote = re.compile(r"[^\w!#$%&'*+,.:;<=>?^`|~-]")

has \w in it. Should that be \s?

I found this when I noticed that SELECT commands on mailboxes with
spaces in their names failed.

----------
nosy: +dmbaggett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue917120>
_______________________________________

From report at bugs.python.org  Tue May 12 22:00:44 2009
From: report at bugs.python.org (Dave Baggett)
Date: Tue, 12 May 2009 20:00:44 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1242158444.07.0.868789444011.issue917120@psf.upfronthosting.co.za>


Dave Baggett <jython at baggett.org> added the comment:

OK, I missed the initial caret in the regex. The mustquote regex is
listing everything that needn't be quoted, and then negating. I still
think it's wrong, though. According to BNF given in the Formal Syntax
section of RFC 3501, you must must quote atom-specials, which are
defined thus:

atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
                  quoted-specials / resp-specials
list-wildcards  = "%" / "*"
quoted-specials = DQUOTE / "\"
resp-specials   = "]"

So I think this regex should do it:

mustquote = re.compile(r'[()\s%*"]|"{"|"\\"|"\]"')

Changing status to bug.

----------
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue917120>
_______________________________________

From report at bugs.python.org  Tue May 12 22:00:54 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 12 May 2009 20:00:54 +0000
Subject: [issue5265] StringIO can duplicate newlines in universal newlines mode
In-Reply-To: <1234650978.85.0.656093494146.issue5265@psf.upfronthosting.co.za>
Message-ID: <1242158454.01.0.393895735034.issue5265@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> Should this issue go under a new ticket?

Yes, it would be preferable as the issue is probably not specific to
io.StringIO. Also, make sure that you include the result of this test-case:

open("testnl.txt", "wb").write("foo\r\nbar\r\n")
open("testnl.txt", "rU").read()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5265>
_______________________________________

From report at bugs.python.org  Tue May 12 22:06:02 2009
From: report at bugs.python.org (Patrick Miller)
Date: Tue, 12 May 2009 20:06:02 +0000
Subject: [issue730473] Add Py_AtInit() startup hook for extenders
In-Reply-To: <1242151632.87.0.870668411267.issue730473@psf.upfronthosting.co.za>
Message-ID: <ff09f8e60905121305x73d13555o6943561b7cf75525@mail.gmail.com>


Patrick Miller <patmiller at users.sourceforge.net> added the comment:

Thanks... I'll submit patches for 2.6, 2.7, and 3.2

On Tue, May 12, 2009 at 2:07 PM, Daniel Diniz <report at bugs.python.org> wrote:
>
> Changes by Daniel Diniz <ajaksu at gmail.com>:
>
>
> ----------
> stage: ?-> test needed
> versions: +Python 2.7, Python 3.2 -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue730473>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730473>
_______________________________________

From report at bugs.python.org  Tue May 12 22:39:43 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 May 2009 20:39:43 +0000
Subject: [issue6000] compile error - PyNumber_InPlaceOr(newfree, allfree) < 0
In-Reply-To: <1242077376.02.0.0771878872904.issue6000@psf.upfronthosting.co.za>
Message-ID: <1242160783.58.0.642312389089.issue6000@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r72589.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6000>
_______________________________________

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: [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  Tue May 12 23:47:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 May 2009 21:47:09 +0000
Subject: [issue6007] distutils tricks you into thinking you can build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1242164829.03.0.62028651191.issue6007@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(or perhaps an announcement can be made on distutils-sig in the hope
that someone step up and fix mingw support?)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Wed May 13 01:12:53 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 12 May 2009 23:12:53 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242169973.87.0.285909399737.issue5977@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Tarek,
Sorry about breaking the compiler option, I was aware that passing None
there would have that risk.

I think anything that breaks people's setup.py shouldn't go into
release26-maint without a really important motivation.

Is there a way to keep self.compiler as an attribute and make
new_compiler work correctly with it?

----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From report at bugs.python.org  Wed May 13 01:27:03 2009
From: report at bugs.python.org (Francis Devereux)
Date: Tue, 12 May 2009 23:27:03 +0000
Subject: [issue5716] Overzealous deprecation of BaseException.message
In-Reply-To: <1239106026.05.0.616331762443.issue5716@psf.upfronthosting.co.za>
Message-ID: <1242170823.91.0.686168443962.issue5716@psf.upfronthosting.co.za>


Changes by Francis Devereux <python.org at devrx.org>:


----------
nosy: +frankoid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5716>
_______________________________________

From report at bugs.python.org  Wed May 13 01:41:32 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 12 May 2009 23:41:32 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1242171692.58.0.297136493867.issue4947@psf.upfronthosting.co.za>


Changes by Jan Kaliszewski <zuo at chopin.edu.pl>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

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: [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 report at bugs.python.org  Wed May 13 03:36:45 2009
From: report at bugs.python.org (Hari Krishna Dara)
Date: Wed, 13 May 2009 01:36:45 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1242178605.49.0.565796062158.issue2972@psf.upfronthosting.co.za>


Hari Krishna Dara <haridara at gmail.com> added the comment:

I hit exactly this same problem today trying to customize sys.path. We
conventionally use .pth file under site-packages to add our custom
library paths, but this is not convenient in development while switching
between branches/checkout directories, so I would like something like
this to work:

def updateADPath(dir):
    """ Determine the root of the AD code given the specific sub
directory and update sys.path. Returns 0 on success. """
    pass

# First try the current directory. If not found, try the main script's
directory.
if updateADPath(os.getcwd()):
    # If not absolute path, the script is in the current dir anyway,
which we have already tried.
    if len(sys.argv) > 0 and sys.argv[0] != '-c' and
os.path.isabs(sys.argv[0]):
       updateADPath(os.path.split(sys.argv[0])[0])

It works quite well as long as I run when the CWD is with in the branch
directory, but if it is outside (such as when running from a windows
shortcut) there is no way to determine the root. Is there an alternative
means to access the raw command-line arguments, it would help me provide
a partial workaround for this problem.

----------
nosy: +haridsv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Wed May 13 04:04:59 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Wed, 13 May 2009 02:04:59 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242180299.51.0.0613076390823.issue5964@psf.upfronthosting.co.za>


Changes by Robert Schuppenies <robert.schuppenies at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Wed May 13 04:35:40 2009
From: report at bugs.python.org (Zach Hirsch)
Date: Wed, 13 May 2009 02:35:40 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1242182140.98.0.356624417746.issue2622@psf.upfronthosting.co.za>


Zach Hirsch <zhirsch at umich.edu> added the comment:

I'm not sure if this is the same problem, but it seems related.  I can
get the same ImportError without involving py2exe or modulefinder:

Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import email.message
>>> sys.modules = sys.modules.copy()
>>> msg = email.message.Message()
>>> msg['From'] = 'foo at bar.com'
>>> msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/email/message.py", line 128, in as_string
    from email.Generator import Generator
  File "/usr/lib/python2.5/email/__init__.py", line 80, in __getattr__
    mod = sys.modules[self.__name__]
KeyError: 'email.generator'

If the "sys.modules = sys.modules.copy()" line is left out, everything
works as expected.

----------
nosy: +zhirsch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
_______________________________________

From report at bugs.python.org  Wed May 13 07:02:12 2009
From: report at bugs.python.org (Vaibhav Mallya)
Date: Wed, 13 May 2009 05:02:12 +0000
Subject: [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 11:30:03 2009
From: report at bugs.python.org (Alvaro)
Date: Wed, 13 May 2009 09:30:03 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1242207003.28.0.349430427745.issue4660@psf.upfronthosting.co.za>


Changes by Alvaro <aloga at ifca.unican.es>:


----------
nosy: +aloga

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Wed May 13 12:01:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 May 2009 10:01:49 +0000
Subject: [issue2813] No float formatting in PyString_FromFormat
In-Reply-To: <1210453747.33.0.971608840544.issue2813@psf.upfronthosting.co.za>
Message-ID: <1242208909.02.0.548784113526.issue2813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I also think it would be good to use PyOS_double_to_string here.  That
does make it impossible to format long doubles, though, except by doing
a possibly lossy conversion to double first.

As far as I can see, Python doesn't use long double anywhere outside the
ctypes module, so I'm not sure that long double support really matters
right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2813>
_______________________________________

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: [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 12:56:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2009 10:56:44 +0000
Subject: [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: <1242212204.46.0.51279667518.issue6009@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Pesonally I would prefer that the deprication be reversed.  In most of
my optparse use cases it is more convenient than calling set_defaults. 
In fact, I'm not sure I've ever used set_defaults, though I am glad that
it exists since I can certainly envision use cases for it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6009>
_______________________________________

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: [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:03:35 2009
From: report at bugs.python.org (Baptiste Carvello)
Date: Wed, 13 May 2009 11:03:35 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1242212615.08.0.211790667442.issue6011@psf.upfronthosting.co.za>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

And here comes the patch

----------
keywords: +patch
Added file: http://bugs.python.org/file13975/text_file.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Wed May 13 13:44:37 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 13 May 2009 11:44:37 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242215077.11.0.489340985564.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Francesco,

> if you want to encode the newline character, 
> this should be done by both parseString and 
> setAttribute methods. Otherwise, the 
> behaviour is not symmetric.

I believe you still don't see the issue. The behaviour is not symmetric
*now*. You store a '\n' in an attribute value with setAttribute(), save
the document to XML, load it again and out comes a space where the '\n'
should have been.

The point is that parseString() behaves correctly, but serializing does
not. There is only one side to fix, because only one side is broken.

> If you want to encode the newline in different 
> manner, you should develop a patch that
> introduces this kind of encoding in both 
> parseString and setAttribute methods.

It would be pointless to do the encoding in setAttribute(). The valid
ways to XML-encode a '\n' character are '&#xA', '&#x0A' or '&#10'. Doing
so in setAttribute() would produce doubly encoded output, like this:
'&amp;#10'. This is even more wrong.

However, if parseString() encounters a '&#10' in the input, it correctly
translates this to '\n' in the DOM. As I said, there is nothing to fix
in parsing, this exercise is about getting minidom to actually *output*
a '&#10;' where appropriate. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

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: [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 13:47:24 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 May 2009 11:47:24 +0000
Subject: [issue5990] Memory leak in os.rename() and other functions
In-Reply-To: <1241988294.2.0.773567754843.issue5990@psf.upfronthosting.co.za>
Message-ID: <1242215244.04.0.643320351674.issue5990@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I opened #6012 to handle O& memory leak issue.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5990>
_______________________________________

From report at bugs.python.org  Wed May 13 13:57:21 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 13 May 2009 11:57:21 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242215841.18.0.214472836893.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

Daniel Diniz: 

The proposed behaviour is correct:
http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html#charescaping

"In attribute values, the character information items 
TAB (#x9), newline (#xA), and carriage-return (#xD) 
are represented by "&#x9;", "&#xA;", and "&#xD;" respectively."

Since the behaviour is correct, it is also desirable. :-)

I don't think that this change could cause existing solution to break
since the current inconsistency in handling these characters make it
impossible to rely on this anyway.

Thanks for putting up the unit test diff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May 13 14:11:16 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 13 May 2009 12:11:16 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242216676.91.0.732178317351.issue5752@psf.upfronthosting.co.za>


Changes by Tomalak <M8R-t1tut01 at mailinator.com>:


Removed file: http://bugs.python.org/file13919/minidom.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May 13 14:11:58 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 13 May 2009 12:11:58 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242216718.27.0.86521183828.issue5752@psf.upfronthosting.co.za>


Changes by Tomalak <M8R-t1tut01 at mailinator.com>:


Added file: http://bugs.python.org/file13977/minidom.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May 13 14:14:35 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 13 May 2009 12:14:35 +0000
Subject: [issue6007] distutils tricks you into thinking you can
	build	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1242216875.23.0.554007199202.issue6007@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> 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.

I have an extension which doesn't use it and can't be loaded when built
with mingw32, so I think the issue goes beyond localtime().

> I think this is exaggerating the actual state. The compiler is
> certainly supported.

Can you elaborate on what "supported" means?  To me, it would mean that
it could build all the same Python extensions which MSVC can build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Wed May 13 14:16:27 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 13 May 2009 12:16:27 +0000
Subject: [issue5752] xml.dom.minidom does not escape newline characters within
	attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242216987.79.0.823961196745.issue5752@psf.upfronthosting.co.za>


Tomalak <M8R-t1tut01 at mailinator.com> added the comment:

I changed the patch to include support for TAB characters, which were
also left unencoded before.

Also I switched encoding from '&#13;' etc. to '&#xD;'. This is
equivalent, but the spec uses the latter variant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May 13 14:17:35 2009
From: report at bugs.python.org (Tomalak)
Date: Wed, 13 May 2009 12:17:35 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242217055.64.0.073090052429.issue5752@psf.upfronthosting.co.za>


Changes by Tomalak <M8R-t1tut01 at mailinator.com>:


----------
title: xml.dom.minidom does not escape newline characters within attribute values -> xml.dom.minidom does not escape CR, LF and TAB characters within attribute values

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May 13 14:21:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 May 2009 12:21:24 +0000
Subject: [issue6010] unable to retrieve latin-1 encoded data from sqlite3
In-Reply-To: <1242210908.7.0.745434418713.issue6010@psf.upfronthosting.co.za>
Message-ID: <1242217284.64.0.348280350838.issue6010@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Confirmed here, tested with python2.6 
on Linux with sys.stding.encoding == 'ISO-8859-1'
on Windows with sys.stdin.encoding == 'cp437'

>>> import sqlite3
>>> db = sqlite3.connect(':memory:')
>>> cur = db.cursor()
>>> cur.execute("create table foo (x)")
>>> cur.execute("insert into foo values ('caf?')")
>>> cur.execute("select * from foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
sqlite3.OperationalError: Could not decode to UTF-8 column 'x' with text
'caf?'


It seems that sqlite3 expects strings to be utf-8 encoded.
It works fine if you pass unicode strings, and with python 3.0.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6010>
_______________________________________

From report at bugs.python.org  Wed May 13 15:08:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2009 13:08:12 +0000
Subject: [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: <1242220092.27.0.643256897538.issue5994@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I added 'variables' and 'functions' section to module docstring parallel
to the way 'time' does it, and documented 'version' there.

Checked in in r72597, r72598, and in r72599, r72600.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5994>
_______________________________________

From report at bugs.python.org  Wed May 13 15:42:20 2009
From: report at bugs.python.org (Renaud Blanch)
Date: Wed, 13 May 2009 13:42:20 +0000
Subject: [issue1672568] silent error in email.message.Message.get_payload
Message-ID: <1242222140.86.0.150174068586.issue1672568@psf.upfronthosting.co.za>


Renaud Blanch <rndblnch at gmail.com> added the comment:

looks very good to me.
thanks daniel for your work
renaud

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672568>
_______________________________________

From report at bugs.python.org  Wed May 13 16:33:02 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 13 May 2009 14:33:02 +0000
Subject: [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  Wed May 13 16:38:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 May 2009 14:38:10 +0000
Subject: [issue6013] json slower than simplejson
In-Reply-To: <1242225181.83.0.814831398624.issue6013@psf.upfronthosting.co.za>
Message-ID: <1242225490.38.0.472792385904.issue6013@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is probably because your simplejson is much more recent than the
json version shipped with 2.6.
Can you try again with trunk and post the numbers?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6013>
_______________________________________

From report at bugs.python.org  Wed May 13 16:55:56 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 13 May 2009 14:55:56 +0000
Subject: [issue6013] json slower than simplejson
In-Reply-To: <1242225490.38.0.472792385904.issue6013@psf.upfronthosting.co.za>
Message-ID: <4A0ADF79.5050600@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

Here are the numbers from trunk (rev ) and release26-maint branch (rev ):

c:\svn\release26-maint\PCbuild>python -m timeit -s "from json import loads, dumps" "loads(dumps(range(32)))"
1000 loops, best of 3: 726 usec per loop

c:\svn\release26-maint\PCbuild>cd ..\..\trunk\PCbuild

c:\svn\trunk\PCbuild>python -m timeit -s "from json import loads, dumps" "loads(dumps(range(32)))"
10000 loops, best of 3: 33.5 usec per loop

So, the performance issue seems fixed in trunk but not in release26-maint.

(This stuff is an issue for me since I want to use jsonrpc on
an embedded system.  Cross-compiling Python is a pain, but installing
simplejson which uses setuptools is even more painful.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6013>
_______________________________________

From report at bugs.python.org  Wed May 13 17:06:29 2009
From: report at bugs.python.org (Francesco Sechi)
Date: Wed, 13 May 2009 15:06:29 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1242227189.2.0.462885059335.issue5752@psf.upfronthosting.co.za>


Changes by Francesco Sechi <francesco.sechi at iet.unipi.it>:


----------
nosy:  -sechi_francesco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed May 13 17:07:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 May 2009 15:07:27 +0000
Subject: [issue6013] json slower than simplejson
In-Reply-To: <1242225181.83.0.814831398624.issue6013@psf.upfronthosting.co.za>
Message-ID: <1242227247.41.0.293697931496.issue6013@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Given the amount of changed code between the two simplejson versions,
I'm afraid there's no way the new version will be backported to
release26-maint. You can probably do the backport manually in your
Python install, though (or bite the bullet and use SVN trunk, which is
rather stable currently).

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6013>
_______________________________________

From report at bugs.python.org  Wed May 13 17:09:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 May 2009 15:09:47 +0000
Subject: [issue5990] Memory leak in os.rename() and other functions
In-Reply-To: <1241988294.2.0.773567754843.issue5990@psf.upfronthosting.co.za>
Message-ID: <1242227387.62.0.638337635637.issue5990@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +enhance getargs O& to accept cleanup function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5990>
_______________________________________

From report at bugs.python.org  Wed May 13 17:10:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 May 2009 15:10:09 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242227409.68.0.515900624239.issue6012@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
priority:  -> normal
stage:  -> patch review
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Wed May 13 17:53:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 May 2009 15:53:07 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242229987.52.0.545866450685.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A few comments:

(1) I agree that signed overflows should be avoided
where possible.

(2) I think some of the changes in the latest patch
(fix-overflows-final.patch) are unnecessary, and
decrease readability a bit. An example is the following
chunk for the x_divrem function in Objects/longobject.c.

@@ -1799,7 +1799,7 @@ x_divrem(PyLongObject *v1, PyLongObject *w1, PyLongObject **prem)
 	k = size_v - size_w;
 	a = _PyLong_New(k + 1);
 
-	for (j = size_v; a != NULL && k >= 0; --j, --k) {
+	for (j = size_v; a != NULL && k >= 0; j = (unsigned)j - 1 , k = (unsigned)k - 1) {
 		digit vj = (j >= size_v) ? 0 : v->ob_digit[j];
 		twodigits q;
 		stwodigits carry = 0;

In this case it's easy to see from the code that j and k
will always be nonnegative, so replacing --j with j =
(unsigned)j - 1 is unnecessary.  (This chunk no longer
applies for 2.7 and 3.1, btw, since x_divrem got
rewritten recently.)  Similar comments apply to the
change:

-			min_gallop -= min_gallop > 1;
+			if (min_gallop > 1) min_gallop = (unsigned)min_gallop - 1;

in Objects/listobject.c.  Here it's even clearer that
the cast is unnecessary.

I assume these changes were made to silence warnings from
-Wstrict-overflow, but I don't think that should be a goal:
I'd suggest only making changes where there's a genuine
possibility of overflow (even if it's a remote one), and
leaving the code unchanged if it's reasonably easy to
see that overflow is impossible.


(3) unicode_hash also needs fixing, as do the lookup
algorithms for set and dict.  Both use overflowing
arithmetic on signed types as a matter of course.
Probably a good few of the hash algorithms for the
various object types in Objects/ are suspect.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed May 13 18:01:09 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 13 May 2009 16:01:09 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242230469.85.0.373271661283.issue1621@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

"""I assume these changes were made to silence warnings from
-Wstrict-overflow, but I don't think that should be a goal:
I'd suggest only making changes where there's a genuine
possibility of overflow (even if it's a remote one), and
leaving the code unchanged if it's reasonably easy to
see that overflow is impossible."""

There is a lot of value in being able to compile with -Wstrict-overflow 
and know that every warning omitted is something to be looked at.  I 
think it is advantageous to make all code pass this.  Having any 
"expected" warnings during compilation tends to lead people to ignore 
all warnings.

That said, I agree those particular examples of unnecessary casts are 
ugly and should be written differently if they are actually done to 
prevent a warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed May 13 18:03:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 May 2009 16:03:57 +0000
Subject: [issue4050] inspect.findsource() returns binary data for shared
	library modules
In-Reply-To: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>
Message-ID: <1242230637.5.0.101891423383.issue4050@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's true inspect.findsource() behaves likes this, but help() has only
been broken very recently (and only in py3k), so I suggest these are
separate bugs.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4050>
_______________________________________

From report at bugs.python.org  Wed May 13 18:28:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2009 16:28:07 +0000
Subject: [issue4050] inspect.findsource() returns binary data for shared
	library modules
In-Reply-To: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>
Message-ID: <1242232087.7.0.38418805097.issue4050@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4050>
_______________________________________

From report at bugs.python.org  Wed May 13 18:43:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 May 2009 16:43:53 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1242233033.04.0.778059477464.issue4625@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Was python installed with another user account, or a "just for me" install?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed May 13 18:45:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 May 2009 16:45:42 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242233142.74.0.8338713285.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> There is a lot of value in being able to compile with -Wstrict-overflow 
> and know that every warning omitted is something to be looked at.

I agree in principle; this certainly applies to -Wall.  But -Wstrict-
overflow doesn't do a particularly good job of finding signed overflow
cases:  there are a good few false positives, and it doesn't pick up
the many cases of actual everyday signed overflow e.g., in unicode_hash, 
byteshash, set_lookkey, etc.), so it doesn't seem a particular good basis 
for code rewriting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed May 13 18:48:19 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 13 May 2009 16:48:19 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242233299.17.0.561760132682.issue1621@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

You should be using gcc 4.4 to get the best warning behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed May 13 19:00:18 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 May 2009 17:00:18 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1242234018.75.0.22807581408.issue4832@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think I found the relevant documentation:
http://wiki.tcl.tk/1842
"""
On Unix, when typing a filename without extension, the first extension
belonging to the currently selected filetype will be appended to the
filename. On Windows, this is not the case, but one can define a fixed
extension with the -defaultextension option. To get the same behaviour
on Unix, use -defaultextension {}.
"""

I tried to add "defaultextension=.py", (see attached patch) the problem
is that now it seems impossible to create a file without an extension...

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file13978/defaultextension.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Wed May 13 19:45:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2009 17:45:30 +0000
Subject: [issue4050] inspect.findsource() returns binary data for shared
	library modules
In-Reply-To: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>
Message-ID: <1242236730.89.0.633697550279.issue4050@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patches applied to 2.7 in r72605 and 3.1 in r72607, after discussion on
#python-dev.  Blocked on 2.6 since it represents a behavior change and
doesn't actually break anything in the 2 series.

The change that introduced the pydoc regression was not backported to
3.0, which opens the question of whether or not this fix should be
backported.

----------
priority: release blocker -> normal
resolution:  -> fixed
stage: patch review -> commit review
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4050>
_______________________________________

From report at bugs.python.org  Wed May 13 19:47:34 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 May 2009 17:47:34 +0000
Subject: [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: <1242236854.77.0.982382888247.issue5956@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"Is a directory"? I suppose you are trying to install from a source tar
ball? What happens when you try to "ls" this file?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Wed May 13 20:02:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2009 18:02:55 +0000
Subject: [issue4050] inspect.findsource() returns binary data for shared
	library modules
In-Reply-To: <1223263246.04.0.311292342093.issue4050@psf.upfronthosting.co.za>
Message-ID: <1242237775.13.0.419727433849.issue4050@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Decision is not to backport.

----------
status: open -> closed
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4050>
_______________________________________

From report at bugs.python.org  Wed May 13 21:07:03 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 19:07:03 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1242241623.67.0.0695894680592.issue4832@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Amaury,
Your patch also forces '.py' to any saved file on Linux, but using
'defaultextension = ""' it works correctly here. Does if fix things on
Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Wed May 13 21:46:44 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Wed, 13 May 2009 19:46:44 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1242244004.57.0.672979149144.issue4832@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

Trying to patch the latest revision 72608 and it didnt work, here on winxp. 

C:\prg\Python30\Lib\idlelib>svn update
Restored 'IOBinding.py'
At revision 72608.

C:\prg\Python30\Lib\idlelib>patch IOBinding.py defaultextension.patch
--verbose
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: Lib/idlelib/IOBinding.py
|===================================================================
|--- Lib/idlelib/IOBinding.py   (revision 72282)
|+++ Lib/idlelib/IOBinding.py   (working copy)
--------------------------
Patching file IOBinding.py using Plan A...
Hunk #1 succeeded at 480 (offset -45 lines).
Hmm...  Ignoring the trailing garbage.
done


If I do the patch by hand, it works. All files are saved with ext. .py.
When set 'defaultextension = ""', it is save well too, but then IDLE
crashed immediately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Wed May 13 22:05:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 May 2009 20:05:41 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242245141.48.0.021861166145.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks Ismail.  I'm currently using gcc-4.4 with the -ftrapv (not 
-fwrapv!) option to see how much breaks.  (Answer: quite a lot. :-[ )

I'm finding many overflow checks that look like:

	size = Py_SIZE(a) * n;
	if (n && size / n != Py_SIZE(a)) {
		PyErr_SetString(PyExc_OverflowError,
			"repeated bytes are too long");
		return NULL;
	}

where size and n have type Py_ssize_t.  That particular one comes
from bytesobject.c (in py3k), but this style of check occurs
frequently throughout the source.

Do people think that all these should be fixed?  

The fix itself s reasonably straightforward:  instead of multiplying
and then checking for an overflow that's already happened (and hence
has already invoked undefined behaviour according to the standards),
get an upper bound for n *first* by dividing PY_SSIZE_T_MAX
by Py_SIZE(a) and use that to do the overflow check *before*
the multiplication.  It shouldn't be less efficient:  either way
involves an integer division, a comparison, and a multiplication.

The hard part is finding all the places that need to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed May 13 22:14:28 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 13 May 2009 20:14:28 +0000
Subject: [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: <1242245668.66.0.0450344806051.issue5956@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Indeed, this is Python 3.1b1 built from source on MacOS X 10.4.1 Tiger 
(Intel).

MacOS considers some of these win*.exe files directories.  See the 
attached picture and below.

% ls -l Python-3.1b1/Lib/distutils/command/win*
-rw-r--r--   1 jean  jean   61440 Jul 15  2008 Python-
3.1b1/Lib/distutils/command/wininst-6.0.1.exe
-rw-r--r--   1 jean  jean   65536 Jul 15  2008 Python-
3.1b1/Lib/distutils/command/wininst-7.1.1.exe
-rw-r--r--   1 jean  jean   61440 Jan 20 13:25 Python-
3.1b1/Lib/distutils/command/wininst-8.0.1.exe
-rw-r--r--   1 jean  jean  224256 Jan 29 05:08 Python-
3.1b1/Lib/distutils/command/wininst-9.0-amd64.1.exe
-rw-r--r--   1 jean  jean  196096 Jan 29 05:08 Python-
3.1b1/Lib/distutils/command/wininst-9.0.exe

Python-3.1b1/Lib/distutils/command/wininst-6.0.exe:

Python-3.1b1/Lib/distutils/command/wininst-7.1.exe:

Python-3.1b1/Lib/distutils/command/wininst-8.0.exe:

Python-3.1b1/Lib/distutils/command/wininst-9.0-amd64.exe:

% ls -l Python-3.1b1/Lib/distutils/command/
total 2240
....
-rw-r--r--   1 jean  jean   61440 Jul 15  2008 wininst-6.0.1.exe
drwxr-xr-x   2 jean  jean      68 May  7 09:10 wininst-6.0.exe
-rw-r--r--   1 jean  jean   65536 Jul 15  2008 wininst-7.1.1.exe
drwxr-xr-x   2 jean  jean      68 May  7 09:10 wininst-7.1.exe
-rw-r--r--   1 jean  jean   61440 Jan 20 13:25 wininst-8.0.1.exe
drwxr-xr-x   2 jean  jean      68 May  7 09:10 wininst-8.0.exe
-rw-r--r--   1 jean  jean  224256 Jan 29 05:08 wininst-9.0-amd64.1.exe
drwxr-xr-x   2 jean  jean      68 May  7 09:10 wininst-9.0-amd64.exe
-rw-r--r--   1 jean  jean  196096 Jan 29 05:08 wininst-9.0.exe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Wed May 13 22:28:39 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 13 May 2009 20:28:39 +0000
Subject: [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: <1242246519.52.0.427691850545.issue5956@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Another attempt to attach the image.

----------
Added file: http://bugs.python.org/file13979/Issue5956.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Wed May 13 22:58:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 May 2009 20:58:29 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242248309.07.0.900383605185.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> [and then perform the multiplication unsigned, to silence the
> warning - right?]

That wasn't actually what I was thinking:  I was proposing to rewrite it 
as:

	if (Py_SIZE(a) > 0 && n > PY_SSIZE_T_MAX/Py_SIZE(a)) {
		PyErr_SetString(PyExc_OverflowError,
			"repeated bytes are too long");
		return NULL;
	}
	size = Py_SIZE(a) * n;

The multiplication should be safe from overflow, and I don't get
any warning at all either with this rewrite (using -O3 -Wall -Wextra -
Wsigned-overflow=5) or from the original code, so there's nothing to 
silence.

> I think there is a second solution: perform the multiplication
> unsigned in the first place.

That would work too.  I find the above code clearer, though.  It's not 
immediately obvious to me that the current overflow condition actually 
works, even assuming wraparound on overflow; I find myself having to 
think about the mathematics every time.

In general, it seems to me that the set of places reported by -Wsigned-
overflow is a poor match for the set of places that need to be fixed.  -
Wsigned-overflow only gives a warning when that particular version of 
gcc, with those particular flags, happens to make use of the no-overflow 
assumption for some particular optimization.  Certainly each of the 
places reported by -Wsigned-overflow should be investigated, but I don't 
believe it's worth 'fixing' correct code just to get rid of warnings 
from this particular warning option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed May 13 23:02:16 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:02:16 +0000
Subject: [issue1523] xdrlib fails to detect overflow (struct bug?)
In-Reply-To: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za>
Message-ID: <1242248536.12.0.247790422566.issue1523@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

On trunk, I get the described struct behavior with " DeprecationWarning:
struct integer overflow masking is deprecated". The xdr.py script gives:
18446744073709551615 -> ffffffff -> 4294967295

On py3k, both raise "struct.error: argument out of range".

Tested on Linux ia32.

----------
nosy: +ajaksu2
stage:  -> test needed
versions: +Python 2.6, Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1523>
_______________________________________

From report at bugs.python.org  Wed May 13 23:07:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 May 2009 21:07:48 +0000
Subject: [issue1523] xdrlib fails to detect overflow (struct bug?)
In-Reply-To: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za>
Message-ID: <1242248868.25.0.119867274398.issue1523@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take a look.

----------
assignee:  -> marketdickinson
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1523>
_______________________________________

From report at bugs.python.org  Wed May 13 23:08:54 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:08:54 +0000
Subject: [issue731991] find correct socklen_t type
Message-ID: <1242248934.62.0.452666477846.issue731991@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue731991>
_______________________________________

From report at bugs.python.org  Wed May 13 23:10:28 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:10:28 +0000
Subject: [issue1739648] zipfile.testzip() using progressive file reads
Message-ID: <1242249028.79.0.83578372419.issue1739648@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> resource usage
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739648>
_______________________________________

From report at bugs.python.org  Wed May 13 23:17:05 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:17:05 +0000
Subject: [issue1428655] Use PyOS_snprintf for static buffers
Message-ID: <1242249425.89.0.245899079644.issue1428655@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Does anyone want to adopt this one? :)

----------
nosy: +ajaksu2
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1428655>
_______________________________________

From report at bugs.python.org  Wed May 13 23:49:48 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:49:48 +0000
Subject: [issue1200] Allow array.array to be parsed by the t# format unit.
In-Reply-To: <1190697931.82.0.81567230307.issue1200@psf.upfronthosting.co.za>
Message-ID: <1242251388.51.0.846102148741.issue1200@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

PyBUF_CHARACTER is now gone, and getargs.c reads:

          /*TEO: This can be eliminated --- here only for backward
            compatibility */
        case 't': { /* 8-bit character buffer, read-only access */

----------
nosy: +ajaksu2, pitrou
stage:  -> patch review
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200>
_______________________________________

From report at bugs.python.org  Wed May 13 23:51:20 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:51:20 +0000
Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h
In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za>
Message-ID: <1242251480.18.0.0298622925642.issue1783@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1783>
_______________________________________

From report at bugs.python.org  Wed May 13 23:53:26 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:53:26 +0000
Subject: [issue1467201] size_t warnings on OSX 10.3
Message-ID: <1242251606.23.0.566655522268.issue1467201@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Unless someone can confirm the warnings still exist, this will be closed.

----------
nosy: +ajaksu2
priority: normal -> low
stage:  -> test needed
status: pending -> open
type:  -> behavior
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467201>
_______________________________________

From report at bugs.python.org  Wed May 13 23:55:16 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 21:55:16 +0000
Subject: [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1242251716.75.0.0152050755061.issue1866@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
keywords: +patch
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
_______________________________________

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: [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 00:02:52 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:02:52 +0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1242252172.18.0.332528417401.issue2005@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

That would be issue 1983.

----------
dependencies: +Return from fork() is pid_t, not int
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
_______________________________________

From report at bugs.python.org  Thu May 14 00:02:56 2009
From: report at bugs.python.org (Ralf Seliger)
Date: Wed, 13 May 2009 22:02:56 +0000
Subject: [issue6014] No shell prompt when a graphics window that was started
	from IDLE is closed
In-Reply-To: <1242252085.07.0.824128250707.issue6014@psf.upfronthosting.co.za>
Message-ID: <1242252176.17.0.628059139476.issue6014@psf.upfronthosting.co.za>


Changes by Ralf Seliger <admin at kreidestaub.de>:


----------
title: No shell prompt when a graphics that was started from IDLE is closed -> No shell prompt when a graphics window that was started from IDLE is closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6014>
_______________________________________

From report at bugs.python.org  Thu May 14 00:02:57 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:02:57 +0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1242252177.5.0.651012838939.issue1983@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Is this pending for trunk and py3k too or just for 2.5 (and hence can be
closed)?

----------
nosy: +ajaksu2
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
_______________________________________

From report at bugs.python.org  Thu May 14 00:06:11 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:06:11 +0000
Subject: [issue1932] Cosmetic patch to supress compiler warning
In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za>
Message-ID: <1242252371.41.0.82108646259.issue1932@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1932>
_______________________________________

From report at bugs.python.org  Thu May 14 00:07:47 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:07:47 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>
Message-ID: <1242252467.05.0.000375274846647.issue1294@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294>
_______________________________________

From report at bugs.python.org  Thu May 14 00:18:02 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:18:02 +0000
Subject: [issue2492] Check implementation of new buffer interface for PyString
	in 2.6
In-Reply-To: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za>
Message-ID: <1242253082.87.0.285082463652.issue2492@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2492>
_______________________________________

From report at bugs.python.org  Thu May 14 00:28:51 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:28:51 +0000
Subject: [issue2325] isinstance(anything,
	MetaclassThatDefinesInstancecheck) raises instead of returning False
In-Reply-To: <1205772306.86.0.317312162506.issue2325@psf.upfronthosting.co.za>
Message-ID: <1242253731.82.0.564859618721.issue2325@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This now works correctly (returns False) in release26-maint, trunk and py3k.

----------
nosy: +ajaksu2
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2325>
_______________________________________

From report at bugs.python.org  Thu May 14 00:32:19 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:32:19 +0000
Subject: [issue3180] Interrupts are lost during readline PyOS_InputHook
	processing
In-Reply-To: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za>
Message-ID: <1242253939.83.0.388091687489.issue3180@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Michael,
How does this interact with the fix from issue 706406?

----------
components: +Extension Modules -None
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3180>
_______________________________________

From report at bugs.python.org  Thu May 14 00:33:41 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:33:41 +0000
Subject: [issue1534607] IndexError: Add bad index to msg
Message-ID: <1242254021.33.0.535418232902.issue1534607@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1534607>
_______________________________________

From report at bugs.python.org  Thu May 14 00:34:38 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:34:38 +0000
Subject: [issue3070] Wrong size calculation in posix_execve
In-Reply-To: <1213054131.08.0.268305843949.issue3070@psf.upfronthosting.co.za>
Message-ID: <1242254078.07.0.896099461795.issue3070@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +haypo, loewis
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3070>
_______________________________________

From report at bugs.python.org  Thu May 14 00:37:53 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:37:53 +0000
Subject: [issue2981] confusing action of struct.pack and struct.unpack with
	fmt 'p'
In-Reply-To: <1211903770.4.0.523120419892.issue2981@psf.upfronthosting.co.za>
Message-ID: <1242254273.51.0.794870353755.issue2981@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2981>
_______________________________________

From report at bugs.python.org  Thu May 14 00:54:09 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 22:54:09 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1242255249.78.0.0174715734743.issue2521@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed on release26-maint and trunk.

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Thu May 14 01:01:55 2009
From: report at bugs.python.org (Jerome)
Date: Wed, 13 May 2009 23:01:55 +0000
Subject: [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 01:31:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 May 2009 23:31:03 +0000
Subject: [issue2492] Check implementation of new buffer interface for PyString
	in 2.6
In-Reply-To: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za>
Message-ID: <1242257463.23.0.799243338237.issue2492@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Uh, this was done a long time ago.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2492>
_______________________________________

From report at bugs.python.org  Thu May 14 01:42:45 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 23:42:45 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1242258165.14.0.0842280092559.issue1376292@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +Documentation for Descriptors in the main docs
stage:  -> needs patch
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_______________________________________

From report at bugs.python.org  Thu May 14 01:43:49 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 May 2009 23:43:49 +0000
Subject: [issue966625] Documentation for Descriptors in the main docs
Message-ID: <1242258229.29.0.243785651355.issue966625@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Maybe we should close this in favor of issue 1376292?

----------
nosy: +ajaksu2
stage:  -> needs patch
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue966625>
_______________________________________

From report at bugs.python.org  Thu May 14 01:58:03 2009
From: report at bugs.python.org (Alan McIntyre)
Date: Wed, 13 May 2009 23:58:03 +0000
Subject: [issue1739648] zipfile.testzip() using progressive file reads
Message-ID: <1242259083.39.0.234909042047.issue1739648@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

It would appear that the change to testzip has already been made:

http://mail.python.org/pipermail/python-checkins/2008-August/072892.html
http://mail.python.org/pipermail/python-3000-checkins/2008-August/004310.html

I can add some tests, though.  I'll submit another patch shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739648>
_______________________________________

From report at bugs.python.org  Thu May 14 02:36:46 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 00:36:46 +0000
Subject: [issue966625] Documentation for Descriptors in the main docs
Message-ID: <1242261406.61.0.485446744558.issue966625@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll check but much of this has been done already.

----------
assignee:  -> rhettinger
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue966625>
_______________________________________

From report at bugs.python.org  Thu May 14 03:58:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 May 2009 01:58:54 +0000
Subject: [issue1932] Cosmetic patch to supress compiler warning
In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za>
Message-ID: <1242266334.67.0.586272646152.issue1932@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

There is no warning now. Seems to be fixed.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1932>
_______________________________________

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: [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 05:33:23 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 14 May 2009 03:33:23 +0000
Subject: [issue6016] Use shipped zlib if the system version is bad
In-Reply-To: <1242266748.56.0.906983355468.issue6016@psf.upfronthosting.co.za>
Message-ID: <1242272003.9.0.808398466586.issue6016@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

We'd be asking for trouble with this: incompatible shipped and system
versions or having to build the shipped version. All that for working
around the rare case where the user doesn't have a valid zlib makes no
sense :)

----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6016>
_______________________________________

From report at bugs.python.org  Thu May 14 07:44:05 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 14 May 2009 05:44:05 +0000
Subject: [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 11:00:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 May 2009 09:00:20 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242291620.45.0.0551263828295.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This is puzzling, isn't it?

I don't see why.  There's nothing in -Wall -Wextra -Wsigned-overflow
that asks for warnings for code that might overflow. Indeed, I don't
see how any compiler could reasonably provide such warnings without
flagging (almost) every occurrence of arithmetic on signed integers
as suspect.[*] 

The -ftrapv option is useful for catching genuine signed-integer
overflows at runtime, but it can still only catch those cases
that actually get exercised (e.g., by the Python test suite).


[*] Even some operations on unsigned integers would have to be
flagged: the C expression "(unsigned short)x * (unsigned short)y"
also has the potential to invoke undefined behaviour, thanks to
C's integer promotion rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Thu May 14 11:50:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 May 2009 09:50:37 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1242294637.7.0.40568272329.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Aargh!

s/Wsigned-overflow/Wstrict-overflow/g

Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

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: [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:25 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 14 May 2009 10:41:25 +0000
Subject: [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 13:50:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 11:50:04 +0000
Subject: [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: <1242301804.35.0.510282355739.issue6017@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is correct; dict iterators check to see if the size of the dict is
different. However, fixing this problem would require tracking dict
contents during iteration. That strikes me as too inefficient and too
much code for this little case.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Thu May 14 14:29:15 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 May 2009 12:29:15 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242304155.9.0.228985349233.issue6012@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> the same function can be both
> argument parser and cleanup function

Here is an another experimental patch to implement this. (Is this right
usage of PyCObject_FromVoidPtrAndDesc?)

> As not all converters would need or support cleanup, converters
> that do need cleanup could be required to return Py_CLEANUP_SUPPORTED

Well, this is not implemented yet. (I introduced another format
temporary) Does this mean converter should return Py_CLEANUP_SUPPORTED
instead of 1 when cleanup is needed?

----------
Added file: http://bugs.python.org/file13982/experimental_getargs_with_cleanup_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Thu May 14 15:31:43 2009
From: report at bugs.python.org (Alan Pevec)
Date: Thu, 14 May 2009 13:31:43 +0000
Subject: [issue5912] import deadlocks when using fork
In-Reply-To: <1241351428.83.0.293714766412.issue5912@psf.upfronthosting.co.za>
Message-ID: <1242307903.32.0.21533220173.issue5912@psf.upfronthosting.co.za>


Alan Pevec <apevec at gmail.com> added the comment:

Issue is not reproducible with python 2.5, following patch fixes it on
python 2.4:

--- os.py-2.4 2009-05-14 12:54:08.000000000 +0000
+++ os.py 2009-05-14 13:06:21.000000000 +0000
@@ -351,8 +351,8 @@

 __all__.extend(["execl","execle","execlp","execlpe","execvp","execvpe"])

+from errno import ENOENT, ENOTDIR
 def _execvpe(file, args, env=None):
-    from errno import ENOENT, ENOTDIR

     if env is not None:
         func = execve

----------
nosy: +apevec
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5912>
_______________________________________

From report at bugs.python.org  Thu May 14 15:48:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 13:48:09 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242308889.35.0.705559832846.issue5945@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu May 14 16:13:23 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 14:13:23 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1242310403.86.0.185275044361.issue5953@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am inclined to reject this request.  We shouldn't get in the habit of
documenting what functions don't do.  In the past, no one seemed to have
any trouble with xrange() not being comparable to itself.  In the
present, there are many functions that return iterators instead of
lists, so the expectation for comparability will be even lower.

The main problem with anti-documentation is that bringing up the topic
can plant it in a reader's memory in a confusing way, "I think I read
something about ranges and comparability ...".  IOW, just talking about
it makes it more likely that someone will be led to making a fallacious
assumption.

Likewise, I don't want to put in a recommendation about comparing the
repr() of ranges either.  The problem is that the (start,stop,step)
tuples can differ but the ranges can be the same:

   >>> args1 = 0, 101, 5
   >>> args2 = 0, 102, 5
   >>> args1 == args2
   False
   >>> list(range(*args1)) == list(range(*args2))
   True

Also, I'm not worried about this one because comparing the output of
range() was not a common thing to do even in Py2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From report at bugs.python.org  Thu May 14 18:28:48 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 16:28:48 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1242318528.19.0.34547417436.issue2661@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Walter, this is your code.  Care to incorporate any of David's ideas?

David, for my own code, the usual technique for something like
test_repr() is to subclass TestHashMappingProtocol and override the test
method with a customized test_repr() method.

----------
assignee:  -> doerwalter
nosy: +doerwalter
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
_______________________________________

From report at bugs.python.org  Thu May 14 18:40:50 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 14 May 2009 16:40:50 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1242310403.86.0.185275044361.issue5953@psf.upfronthosting.co.za>
Message-ID: <p06240803c631f166a048@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

Sounds right. (1) I was raising the issue in case either the behavior was unintended or the documentation should mention it; (2) I realize that comparing ranges is strange; (3) I understand that range works in 3 the way xrange worked in 2, and that the what's new documentation says that range replaces xrange (4) you're point about ranges with steps clinches the issue, I think -- certainly equality of ranges should not have to compute the range -- they should be thought of as generators (and maybe documented as such -- for all I know, since I haven't looked, they are implemented that way); (5) I agree that range behaves like an iterator -- its documentation at the introduction to sequence tyhpes even points out that in, not in, max, and min are inefficient (6) the specific documentation for range explicitly states that they have very little behavior supporting only indexing, iteration, and len().

Your comments were very helpful in explicitly laying out the issues regarding implementing equality and the relative unimportance of the change in behavior, and I now have the explanation I wanted.

The only thing that still makes me uncomfortable is that it wouldn't be such a big deal to point out in the 3.0 "what's new" document where the change to range is mentioned in a bullet that range supports only indexing, iteration, and len, and that operations such as in and not in and functions such as max and min are inefficient because, except in when true, they require iterating over the entire range. Since these are specified in the actual documentation of range I believe they should be added to the what's new, where the change to range is described. I agree that what things don't do should rarely be documented, but if they no longer do something that they used to do, that should go in the "what's new" document -- at least in the form of an explicit list of what they do do. The only argument I can see against doing that is that the document says that "range() now behaves like xrange() used to behave", but I don't feel that is sufficiently explicit for people who have used range extensively but never or rarely xrange or who don't think about its implications. Maybe the "what's new" should just say that range() acts like an iterator.

All in all I'm satisfied and appreciative, except that I'm still left with the feeling that something about range() should be added to the 3.0 "what's new".
-- 
-- 

        --- Mitchell

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

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: [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:04:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 17:04:31 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1242320671.83.0.888252988375.issue5953@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

At some point, a person just needs to read the regular docs for range().

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

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: [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: [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 19:13:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 17:13:32 +0000
Subject: [issue6021] itertools.grouper
In-Reply-To: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za>
Message-ID: <1242321212.1.0.90470172954.issue6021@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This has been rejected before. 

* It is not a fundamental itertool primitive.  The recipes section in
the docs shows a clean, fast implementation derived from zip_longest().  

* There is some debate on a correct API for odd lengths.  Some people
want an exception, some want fill-in values, some want truncation, and
some want a partially filled-in tuple.  The alone is reason enough not
to set one behavior in stone.

* There is an issue with having too many itertools.  The module taken as
a whole becomes more difficult to use as new tools are added.

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6021>
_______________________________________

From report at bugs.python.org  Thu May 14 19:18:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 17:18:45 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1241666364.76.0.940055680817.issue5953@psf.upfronthosting.co.za>
Message-ID: <1242321525.0.0.470503688169.issue5953@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I should have been clearer.  It is not the function of whatsnew to show
all aspects of 2-to-3 changes.  It is enough to say that range() no
longer returns a list and instead returns what used to be an xrange()
object.  At that point, the job of full documentation of the function is
left to the main docs.  The whatsnew entries are supposed to be very
brief hints about where to look next.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From report at bugs.python.org  Thu May 14 19:23:36 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 17:23:36 +0000
Subject: [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: <1242321816.29.0.0254183805988.issue6022@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> tarek
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From report at bugs.python.org  Thu May 14 19:24:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 17:24:21 +0000
Subject: [issue5912] import deadlocks when using fork
In-Reply-To: <1241351428.83.0.293714766412.issue5912@psf.upfronthosting.co.za>
Message-ID: <1242321861.09.0.00947381847264.issue5912@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

2.4 is no longer supported.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5912>
_______________________________________

From report at bugs.python.org  Thu May 14 19:50:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 17:50:51 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1242323451.82.0.310287619773.issue5006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If no-one objects, I'm going to commit this in a couple of days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Thu May 14 19:52:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 May 2009 17:52:45 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1242323565.75.0.511035285669.issue5006@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Thu May 14 20:10:51 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 14 May 2009 18:10:51 +0000
Subject: [issue5953] Add to "whats new": range(n) != range(n)
In-Reply-To: <1242321525.0.0.470503688169.issue5953@psf.upfronthosting.co.za>
Message-ID: <p06240806c632093d369c@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

Ah. I see. I hadn't realized that. OK, I see how all the pieces fit together now. Thanks for all the explanations. They'll help me understand better what kinds of comments to make on the documentation.
-- 
-- 

        --- Mitchell

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________

From report at bugs.python.org  Thu May 14 20:20:52 2009
From: report at bugs.python.org (Lie Ryan)
Date: Thu, 14 May 2009 18:20:52 +0000
Subject: [issue6021] itertools.grouper
In-Reply-To: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za>
Message-ID: <1242325252.64.0.220898619595.issue6021@psf.upfronthosting.co.za>


Lie Ryan <lie.1296 at gmail.com> added the comment:

All implementations relying on zip or zip_longest breaks with infinite
iterable (e.g. itertools.count()).

And it is not impossible to define a clean, flexible, and familiar API
which will be similar to open()'s mode or unicode error mode. The modes
would be 'error' (default), 'pad', 'truncate', and 'partial' (maybe
should suggest a better name than 'partial')

> There is an issue with having too many itertools.  
> The module taken as a whole becomes more 
> difficult to use as new tools are added.

It should also be weighed that a lot of people are expecting for this
kind of function in itertools. I think there are other functions in
itertools that have more questionable value than groupers, such as starmap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6021>
_______________________________________

From report at bugs.python.org  Thu May 14 20:24:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 18:24:31 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242325471.95.0.703936150009.issue5945@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I understand this is indeed unintuitive. The reason list objects support
the C "mapping protocol" in 3.x is that it is how slicing of lists (and
tuples, for that matter) is implemented. Perhaps the documentation
should carry a warning about this.

Unfortunately, right now there is no easy way in C to check that an
object implements a given ABC.

----------
assignee:  -> georg.brandl
components: +Documentation, Interpreter Core -Library (Lib)
nosy: +georg.brandl, pitrou
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu May 14 20:42:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 18:42:02 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242326522.59.0.262742136265.issue5945@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Personally, I think PyMapping_Check and PySequence_Check should be
deprecated and removed. Like their Python counterparts,
operator.isMappingType() and operation.isSequenceType(), they are
unreliable at best in the face of not LBYL and abcs.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu May 14 20:43:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 18:43:10 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1242326590.83.0.656031896127.issue5006@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As I said on IRC a few days ago, I think the patch is ready to go.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Thu May 14 20:56:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 18:56:24 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1242327384.18.0.882954479182.issue5006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, committed in r72635.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Thu May 14 21:00:03 2009
From: report at bugs.python.org (Jonathan Hayward)
Date: Thu, 14 May 2009 19:00:03 +0000
Subject: [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  Thu May 14 21:09:49 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 19:09:49 +0000
Subject: [issue6021] itertools.grouper
In-Reply-To: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za>
Message-ID: <1242328189.92.0.747001827906.issue6021@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> All implementations relying on zip or zip_longest breaks 
> with infinite iterable (e.g. itertools.count()).

How is it broken?  
Infinite in, infinite out.

>>> def grouper(n, iterable, fillvalue=None):
...    args = [iter(iterable)] * n
...    return zip_longest(*args, fillvalue=fillvalue)

>>> g = grouper(3, count())
>>> next(g)
(0, 1, 2)
>>> next(g)
(3, 4, 5)
>>> next(g)
(6, 7, 8)
>>> next(g)

> And it is not impossible to define a clean, flexible, 
> and familiar API which will be similar to open()'s mode
> or unicode error mode. The modes would be 'error' 
> (default), 'pad', 'truncate', and 'partial'

Of course, it's possible.  I find that to be bad design.  Generally, we
follow Guido's advice and create separate functions rather than overload
a single function with flags -- that is why we have filterfalse()
instead of a flag on filter().  When people suggest an API with multiple
flags, it can be a symptom of hyper-generalization where api complexity
gets substituted for writing a simple function that does what you want
in the first place.  IMO, it is easier to learn the zip(g, g, g) idiom
and customize it to your own needs than to learn a new tool with four
flag options that control its output signature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6021>
_______________________________________

From report at bugs.python.org  Thu May 14 21:26:10 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 May 2009 19:26:10 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242329170.29.0.830372942786.issue5945@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Why did the list implementation get changed in Py3.x?  Is it now
necessary for any subscripting type to put the same method in both the
sequence methods and mapping methods?  Was this change necessary?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu May 14 21:33:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 19:33:40 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1242329170.29.0.830372942786.issue5945@psf.upfronthosting.co.za>
Message-ID: <1242329736.5477.18.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Why did the list implementation get changed in Py3.x?  Is it now
> necessary for any subscripting type to put the same method in both the
> sequence methods and mapping methods?  Was this change necessary?

I think it's a case of foolish consistency. In py3k there are no opcodes
dedicated to slicing anymore, instead the slice object is passed to the
mapping's getitem method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu May 14 22:11:32 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 14 May 2009 20:11:32 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242331892.44.0.425503676225.issue5977@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Proposed patch may fix another windows failure as after recent commit
"unresolved external symbol initfoo" seems to me fixed.

----------
nosy: +rpetrov
Added file: http://bugs.python.org/file13983/issue5977-w32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From report at bugs.python.org  Thu May 14 22:53:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 20:53:09 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1242334389.8.0.181781415784.issue5380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Will try to work out a patch before the RC.

----------
assignee:  -> pitrou
components: +IO
priority:  -> normal
stage:  -> needs patch
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Thu May 14 23:12:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:12:29 +0000
Subject: [issue5628] TextIOWrapper fails with SystemError when reading
	HTTPResponse
In-Reply-To: <1238519324.96.0.24578067817.issue5628@psf.upfronthosting.co.za>
Message-ID: <1242335549.06.0.387708748589.issue5628@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I suppose it is fixed, isn't it?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5628>
_______________________________________

From report at bugs.python.org  Thu May 14 23:15:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 21:15:13 +0000
Subject: [issue5628] TextIOWrapper fails with SystemError when reading
	HTTPResponse
In-Reply-To: <1238519324.96.0.24578067817.issue5628@psf.upfronthosting.co.za>
Message-ID: <1242335713.57.0.711020840462.issue5628@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes

----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5628>
_______________________________________

From report at bugs.python.org  Thu May 14 23:16:39 2009
From: report at bugs.python.org (Baptiste Carvello)
Date: Thu, 14 May 2009 21:16:39 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1242335799.35.0.933727373446.issue6011@psf.upfronthosting.co.za>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

OK, here is also the patch to 'Modules/_io/textio.c', as it is in fact
quite trivial. Choose which one you prefer :-)

Baptiste

----------
Added file: http://bugs.python.org/file13984/textio.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Thu May 14 23:23:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:23:39 +0000
Subject: [issue1664] nntplib is not IPv6-capable
In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za>
Message-ID: <1242336219.95.0.699098122985.issue1664@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your patch is committed in r72640. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1664>
_______________________________________

From report at bugs.python.org  Thu May 14 23:36:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:36:29 +0000
Subject: [issue6020] Create a datetime.timedelta.totalseconds property
In-Reply-To: <1242320277.61.0.875644681622.issue6020@psf.upfronthosting.co.za>
Message-ID: <1242336989.61.0.811580123746.issue6020@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> datetime.timedelta is inconvenient to use...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6020>
_______________________________________

From report at bugs.python.org  Thu May 14 23:36:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:36:34 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1242336994.13.0.851402978003.issue5788@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mw44118

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Thu May 14 23:38:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:38:20 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1242337100.18.0.0127098051873.issue5788@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Given the timing, I fear this will have to wait for 3.2.

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Thu May 14 23:41:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:41:14 +0000
Subject: [issue5803] email/quoprimime: encode and decode are very slow on
	large messages
In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za>
Message-ID: <1242337274.68.0.939038752911.issue5803@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Any news?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5803>
_______________________________________

From report at bugs.python.org  Thu May 14 23:52:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:52:56 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1242337976.91.0.00636745392233.issue5761@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

From report at bugs.python.org  Thu May 14 23:53:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:53:00 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1242337980.72.0.520341639773.issue5761@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +IO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

From report at bugs.python.org  Thu May 14 23:55:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:55:37 +0000
Subject: [issue5918] test_parser crashes when run after some other tests
In-Reply-To: <1241395274.73.0.21825310934.issue5918@psf.upfronthosting.co.za>
Message-ID: <1242338137.01.0.392027729212.issue5918@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch, thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5918>
_______________________________________

From report at bugs.python.org  Thu May 14 23:57:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 21:57:40 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242338260.42.0.283923787725.issue5964@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is the current patch ready for consumption?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 00:02:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 May 2009 22:02:15 +0000
Subject: [issue5844] internal error on write while reading
In-Reply-To: <1240699525.42.0.125859784134.issue5844@psf.upfronthosting.co.za>
Message-ID: <1242338535.25.0.549522113327.issue5844@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r72649.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5844>
_______________________________________

From report at bugs.python.org  Fri May 15 00:25:27 2009
From: report at bugs.python.org (Derek Morr)
Date: Thu, 14 May 2009 22:25:27 +0000
Subject: [issue1664] nntplib is not IPv6-capable
In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za>
Message-ID: <1242339927.92.0.979243047212.issue1664@psf.upfronthosting.co.za>


Derek Morr <derekmorr at psu.edu> added the comment:

Thanks.

Is there any chance of getting bug 1655 fixed as well? imaplib has the 
same issue as nntplib, and the patch is identical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1664>
_______________________________________

From report at bugs.python.org  Fri May 15 00:28:33 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 14 May 2009 22:28:33 +0000
Subject: [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 00:30:41 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 14 May 2009 22:30:41 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242340241.0.0.89276621075.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

The test passes on my machine, but a quick review would definitely be
nice :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 00:36:26 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 14 May 2009 22:36:26 +0000
Subject: [issue6024] regrtest says refleaks are "ok"
In-Reply-To: <1242340112.88.0.36043966948.issue6024@psf.upfronthosting.co.za>
Message-ID: <1242340586.21.0.818037350612.issue6024@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


Added file: http://bugs.python.org/file13986/refleak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6024>
_______________________________________

From report at bugs.python.org  Fri May 15 00:36:33 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 14 May 2009 22:36:33 +0000
Subject: [issue6024] regrtest says refleaks are "ok"
In-Reply-To: <1242340112.88.0.36043966948.issue6024@psf.upfronthosting.co.za>
Message-ID: <1242340593.31.0.380593094373.issue6024@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


Removed 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 00:44:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2009 22:44:56 +0000
Subject: [issue1655] imaplib is not IPv6-capable
In-Reply-To: <1198013698.88.0.631907928895.issue1655@psf.upfronthosting.co.za>
Message-ID: <1242341096.48.0.946996553461.issue1655@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1655>
_______________________________________

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: [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 01:48:23 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 14 May 2009 23:48:23 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242344903.56.0.256776450517.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

If that is the right behavior then yes. Is this documented somewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

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: [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:27:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 May 2009 01:27:10 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242350830.23.0.232646780675.issue5964@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

See http://docs.python.org/reference/datamodel.html#object.__eq__

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

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: [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 03:39:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 May 2009 01:39:19 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
Message-ID: <1242351559.81.0.610328211834.issue3583@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I got a similar problem but here the ISP returned an error/search page
and a "302 Found". test_urllibnet.test_bad_address() failed with
"AssertionError: IOError not raised by urlopen"

>>> import http.client
>>> conn = http.client.HTTPConnection("www.somerandominvalidpage.edu")
>>> conn.request("GET", "/")
>>> r1 = conn.getresponse()
>>> r1.status, r1.reason
(302, 'Found')

test_xmlrpc_net failed for the same reason (see #6027).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Fri May 15 03:46:40 2009
From: report at bugs.python.org (George Sakkis)
Date: Fri, 15 May 2009 01:46:40 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1242352000.73.0.623041933997.issue3135@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

I updated the recipe to also return a `missing_args` tuple - the tuple
of the formal parameters whose value was not provided. This is useful in
cases where one want to distinguish f() from f(None) given "def f(x=None)".

----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri May 15 03:47:41 2009
From: report at bugs.python.org (George Sakkis)
Date: Fri, 15 May 2009 01:47:41 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1242352061.38.0.616471586776.issue3135@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Also updated url: http://code.activestate.com/recipes/551779/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri May 15 03:50:11 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 01:50:11 +0000
Subject: [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za>
Message-ID: <1242352211.51.0.262815431867.issue1286@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1286>
_______________________________________

From report at bugs.python.org  Fri May 15 03:51:24 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 01:51:24 +0000
Subject: [issue1772673] Replacing char* with const char*
Message-ID: <1242352284.86.0.0249755903213.issue1772673@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +replacing char* with const char* in sysmodule.c/.h
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772673>
_______________________________________

From report at bugs.python.org  Fri May 15 03:57:57 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 01:57:57 +0000
Subject: [issue1051] certificate in Lib/test/test_ssl.py expires in February
	2013
In-Reply-To: <1188347976.5.0.452651938293.issue1051@psf.upfronthosting.co.za>
Message-ID: <1242352677.61.0.746162310412.issue1051@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Maybe this should be added to a PEP? 

IMO it would be better if the a new certificate could be issued soon
enough so that test_ssl in any given version works at least until that
version stops being supported.

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1051>
_______________________________________

From report at bugs.python.org  Fri May 15 04:00:01 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 15 May 2009 02:00:01 +0000
Subject: [issue6024] regrtest says refleaks are "ok"
In-Reply-To: <1242340112.88.0.36043966948.issue6024@psf.upfronthosting.co.za>
Message-ID: <1242352801.17.0.686952677128.issue6024@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Applied in r72658 (trunk) and r72660 (py3k).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6024>
_______________________________________

From report at bugs.python.org  Fri May 15 04:05:51 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:05:51 +0000
Subject: [issue1441] Cycles through ob_type aren't freed
In-Reply-To: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za>
Message-ID: <1242353151.4.0.310061478537.issue1441@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441>
_______________________________________

From report at bugs.python.org  Fri May 15 04:08:42 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:08:42 +0000
Subject: [issue1736792] dict reentrant/threading bug
Message-ID: <1242353322.55.0.509137403034.issue1736792@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736792>
_______________________________________

From report at bugs.python.org  Fri May 15 04:10:20 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:10:20 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1242353420.9.0.158018201553.issue1706039@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +IO
nosy: +benjamin.peterson, pitrou
priority:  -> normal
stage:  -> patch review
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706039>
_______________________________________

From report at bugs.python.org  Fri May 15 04:12:28 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:12:28 +0000
Subject: [issue1704474] test_optparse.py mod. for jython
Message-ID: <1242353548.0.0.320861686168.issue1704474@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Can someone ping the Jython tracker for help on this?

----------
nosy: +ajaksu2
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1704474>
_______________________________________

From report at bugs.python.org  Fri May 15 04:21:09 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:21:09 +0000
Subject: [issue1697943] msgfmt cannot cope with BOM
Message-ID: <1242354069.37.0.705626284106.issue1697943@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Unicode
keywords: +patch
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697943>
_______________________________________

From report at bugs.python.org  Fri May 15 04:22:51 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:22:51 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1242354171.08.0.233090036771.issue1692335@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri May 15 04:24:47 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:24:47 +0000
Subject: [issue1598083] Top-level exception handler writes to stdout unsafely
Message-ID: <1242354287.57.0.825524873527.issue1598083@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1598083>
_______________________________________

From report at bugs.python.org  Fri May 15 04:29:04 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:29:04 +0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1242354544.59.0.590358110003.issue1540617@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_______________________________________

From report at bugs.python.org  Fri May 15 04:34:11 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:34:11 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1242354851.58.0.608377992458.issue1530559@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +struct.pack("I", "foo"); struct.pack("L", "foo") should fail
keywords: +patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Fri May 15 04:37:00 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:37:00 +0000
Subject: [issue1687125] cannot catch KeyboardInterrupt when using curses
	getkey()
Message-ID: <1242355020.97.0.548891004748.issue1687125@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Seems related to #706406 and #3180.

----------
nosy: +ajaksu2
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1687125>
_______________________________________

From report at bugs.python.org  Fri May 15 04:38:04 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:38:04 +0000
Subject: [issue1399935] enhance unittest to define tests that *should* fail
Message-ID: <1242355084.42.0.0747259560214.issue1399935@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +michael.foord
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1399935>
_______________________________________

From report at bugs.python.org  Fri May 15 04:38:33 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:38:33 +0000
Subject: [issue1399935] enhance unittest to define tests that *should* fail
Message-ID: <1242355113.38.0.446465523726.issue1399935@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1399935>
_______________________________________

From report at bugs.python.org  Fri May 15 04:43:34 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:43:34 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1242355414.89.0.367229815955.issue1309352@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Fri May 15 04:45:59 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:45:59 +0000
Subject: [issue1306248] Add 64-bit Solaris 9 build instructions to README
Message-ID: <1242355559.76.0.547800749565.issue1306248@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.6, Python 3.1 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1306248>
_______________________________________

From report at bugs.python.org  Fri May 15 04:48:05 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:48:05 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1242355685.18.0.726809369702.issue1284316@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> security
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Fri May 15 04:49:00 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:49:00 +0000
Subject: [issue1244929] hide tests from TestProgram
Message-ID: <1242355740.08.0.691710535305.issue1244929@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +michael.foord
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1244929>
_______________________________________

From report at bugs.python.org  Fri May 15 04:51:35 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:51:35 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1242355895.79.0.11014314006.issue1182143@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Fri May 15 04:53:53 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 02:53:53 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242356033.83.0.610791244712.issue1152248@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +IO
nosy: +benjamin.peterson, pitrou
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 05:00:15 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 03:00:15 +0000
Subject: [issue920573] http libraries throw errors internally in BitTorrent
Message-ID: <1242356415.85.0.0244689602121.issue920573@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I think we should close this, otherwise we'll have to get creative
trying to find bugs that might as well have been fixed.

----------
nosy: +ajaksu2
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue920573>
_______________________________________

From report at bugs.python.org  Fri May 15 05:05:37 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 15 May 2009 03:05:37 +0000
Subject: [issue502236] Asynchronous exceptions between threads
Message-ID: <1242356737.63.0.346849882253.issue502236@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue502236>
_______________________________________

From report at bugs.python.org  Fri May 15 05:06:54 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 15 May 2009 03:06:54 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242356814.13.0.436003884363.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

I am now a bit confused about the semantics of __eq__ for WeakSets. Is a
WeakSet only equal to another WeakSet with the same elements or to any
iterable with the same elements, e.g. list? Because this is how I read
the current implementation. If it is the latter, when should a
NotImplementedError be raised? Whenever the other object is not an Iterable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 06:17:14 2009
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 15 May 2009 04:17:14 +0000
Subject: [issue6021] itertools.grouper
In-Reply-To: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za>
Message-ID: <1242361035.0.0.149941745761.issue6021@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6021>
_______________________________________

From report at bugs.python.org  Fri May 15 09:04:51 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 May 2009 07:04:51 +0000
Subject: [issue920573] http libraries throw errors internally in BitTorrent
Message-ID: <1242371091.2.0.0917978475048.issue920573@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll take another look at it the week.

----------
assignee:  -> rhettinger
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue920573>
_______________________________________

From report at bugs.python.org  Fri May 15 10:04:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 May 2009 08:04:20 +0000
Subject: [issue6019] Minor typos in ctypes docs
In-Reply-To: <1242297684.85.0.343298807561.issue6019@psf.upfronthosting.co.za>
Message-ID: <1242374660.81.0.484472076454.issue6019@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r72661.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6019>
_______________________________________

From report at bugs.python.org  Fri May 15 10:29:41 2009
From: report at bugs.python.org (Yury)
Date: Fri, 15 May 2009 08:29:41 +0000
Subject: [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: [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 10:55:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 May 2009 08:55:26 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1242377726.96.0.631697367058.issue1182143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 5353.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Fri May 15 10:56:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 May 2009 08:56:51 +0000
Subject: [issue5353] Improve IndexError messages with actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1242377811.39.0.572477538547.issue5353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 1182143.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________

From report at bugs.python.org  Fri May 15 11:18:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 May 2009 09:18:38 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242379118.3.0.966878193932.issue1152248@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

> cat temp
this is$#a weird$#file$#
> ./python
Python 3.1b1+ (py3k:72632:72633M, May 15 2009, 05:11:27)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('temp', newline='$#')
[50354 refs]
>>> f.readlines()
['this is$#', 'a weird$#', 'file$#', '\n']

All I did was comment out the 'newline' argument validity check in textio.c.

----------
keywords: +easy
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 12:17:53 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 May 2009 10:17:53 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242382673.36.0.14666956122.issue1152248@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While RDM's quick test is encouraging, I think one of the key things is
going to be developing tests for the various cases:

- binary mode, single byte line ending
- binary mode, multi-byte line ending
- text mode, single byte single char line ending*
- text mode, multi-byte single char line ending
- text mode, multiple char line ending

The text mode tests would need to cover a variety of encodings (e.g.
ASCII, latin-1, UTF-8, UTF-16, UTF-32 and maybe something like koi8-r
and/or some of the CJK codecs).

*if applicable to codec under test

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:13:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 11:13:03 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242385983.16.0.338114783421.issue1152248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

-1 on this idea. readlines() exists precisely because line endings are
special when it comes to text IO (because of the various platform
differences).

If you want to split on any character, you can just use read() followed
by split(). No need to graft additional complexity on the file IO classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:22:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 11:22:18 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242386538.27.0.901829753287.issue6028@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is normal behaviour, actually. The RuntimeError *is* raised, but
you catch it in the except clause and then recurse again ad infinitum.
The interpreter realizes that it "cannot recover from stack overflow",
as the message says, and then bails out.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Fri May 15 13:24:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 11:24:27 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242386667.71.0.929747046844.issue1152248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And it's certainly not easy to do correctly :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:25:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 11:25:15 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242386715.07.0.203604961742.issue1152248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Uh, trying again to remove the keyword :-(

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:34:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 11:34:06 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242387246.57.0.535664194219.issue1152248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, let me qualify my position a bit:
- -1 for abusing the newline parameter
- -1 for abusing readlines()
- +0 on an additional method ("readchunks" was suggested) which does the
splitting, either on a single character or on a string

Please bear in mind the latter should involve, for each of the C and
Python implementations:
- a generic unoptimized version for BufferedIOBase
- a generic unoptimized version for TextIOBase
- an optimized version for BufferedReader/BufferedRandom
- an optimized version for TextIOWrapper

However, it is certainly an interesting task for someone wanting to play
with C code, optimizations, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:46:29 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 May 2009 11:46:29 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242387989.95.0.58508221102.issue1152248@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agree with Antoine - given that the newlines parameter now deals with
Skip's alternate line separator use case, a new method "readrecords"
that takes a mandatory record separator makes more sense than using
readlines to read things that are not lines. (of course, taking the
alternate line ending use case away also reduces the total number of use
cases for the new method).

Note that the problem with the read()+split() approach is that you
either have to read the whole file into memory (which this RFE is trying
to avoid) or you have to do your own buffering and so forth to split
records as you go. Since the latter is both difficult to get right and
very similar to what the IO module already has to do for readlines(), it
makes sense to include the extra complexity there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:46:54 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 May 2009 11:46:54 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242388014.59.0.430003269127.issue1152248@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agree with Antoine - given that the newlines parameter now deals with
Skip's alternate line separator use case, a new method "readrecords"
that takes a mandatory record separator makes more sense than using
readlines to read things that are not lines. (of course, taking the
alternate line ending use case away also reduces the total number of use
cases for the new method).

Note that the problem with the read()+split() approach is that you
either have to read the whole file into memory (which this RFE is trying
to avoid) or you have to do your own buffering and so forth to split
records as you go. Since the latter is both difficult to get right and
very similar to what the IO module already has to do for readlines(), it
makes sense to include the extra complexity there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:47:10 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 May 2009 11:47:10 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242388030.06.0.0495322033178.issue1152248@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 13:50:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 11:50:59 +0000
Subject: [issue1655] imaplib is not IPv6-capable
In-Reply-To: <1198013698.88.0.631907928895.issue1655@psf.upfronthosting.co.za>
Message-ID: <1242388259.01.0.400210419529.issue1655@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r72662, thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1655>
_______________________________________

From report at bugs.python.org  Fri May 15 14:20:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 12:20:22 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1242390022.95.0.595456179484.issue1309352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I confirm this on trunk, using Brad's test script.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Fri May 15 14:36:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 12:36:19 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1242390979.2.0.417543212426.issue1309352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch with a test.

----------
Added file: http://bugs.python.org/file13988/fcntl.patch3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Fri May 15 14:39:38 2009
From: report at bugs.python.org (Hans L)
Date: Fri, 15 May 2009 12:39:38 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242391178.39.0.564123805453.issue1424152@psf.upfronthosting.co.za>


Changes by Hans L <hans at velum.net>:


----------
nosy: +hozn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri May 15 14:49:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 12:49:24 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1242391764.82.0.118928506163.issue1309352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As for the calling convention concern, it seems to me that a sane ABI
wouldn't make a difference between ints and longs - both should fit in a
standard machine word.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Fri May 15 14:51:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 12:51:43 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242391903.03.0.225819613135.issue5964@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why are you confused? You already asked that question earlier in the thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 14:55:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 12:55:18 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1242392118.3.0.84634374218.issue1706039@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does it apply to 3.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706039>
_______________________________________

From report at bugs.python.org  Fri May 15 15:01:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 13:01:46 +0000
Subject: [issue1200] Allow array.array to be parsed by the t# format unit.
In-Reply-To: <1190697931.82.0.81567230307.issue1200@psf.upfronthosting.co.za>
Message-ID: <1242392506.98.0.821433160828.issue1200@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure what t# is for. Jeffrey, have you tried using y* instead?
(you must call PyBuffer_Release at the end)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200>
_______________________________________

From report at bugs.python.org  Fri May 15 15:07:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 13:07:56 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
In-Reply-To: <1242388014.59.0.430003269127.issue1152248@psf.upfronthosting.co.za>
Message-ID: <1242392994.8399.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note that the problem with the read()+split() approach is that you
> either have to read the whole file into memory (which this RFE is trying
> to avoid) or you have to do your own buffering and so forth to split
> records as you go. Since the latter is both difficult to get right and
> very similar to what the IO module already has to do for readlines(), it
> makes sense to include the extra complexity there.

I wonder how often this use case happens though. Usually you first split
on lines, and only then you split on another character or string (think
CSV files, HTTP headers, etc.).

When you don't split on lines, conversely, you probably have a binary
format, and binary formats have more efficient ways of chunking (for
example, a couple of bytes at the beginning indicating the length of the
chunk).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 16:46:13 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 May 2009 14:46:13 +0000
Subject: [issue5353] Improve IndexError messages with actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1242398773.14.0.180227377836.issue5353@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________

From report at bugs.python.org  Fri May 15 16:46:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 May 2009 14:46:36 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1242398796.97.0.708641299648.issue1182143@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Fri May 15 17:25:53 2009
From: report at bugs.python.org (Derek Morr)
Date: Fri, 15 May 2009 15:25:53 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1242401153.2.0.632862630595.issue5625@psf.upfronthosting.co.za>


Changes by Derek Morr <derekmorr at psu.edu>:


----------
nosy: +dmorr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Fri May 15 17:37:20 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 15 May 2009 15:37:20 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242401840.21.0.540177188544.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Maybe because I take the doc too specfic. It says "A rich comparison
method may return the singleton NotImplemented if it does not implement
the operation for a given pair of arguments."

I see the type check of the 'other' object as an operation towards the
equal comparison, since it validates wether 'self' and 'other' can be
equal at all. If they are of a different type, then they cannot be
equal, thus the anwser to "Are 'self' and 'other' equal?" should be
False. This again, would mean an equal operation is implemented and
returning NotImplemented is not the right anwser.

But going through similar code snippets shows otherwise, so my
understanding must be lacking something. Therefore here is patch which
returns NotImplemented.

----------
Added file: http://bugs.python.org/file13989/_weakrefset-notimplemented.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 17:45:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 15:45:45 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1242401840.21.0.540177188544.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242402464.8399.14.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I see the type check of the 'other' object as an operation towards the
> equal comparison, since it validates wether 'self' and 'other' can be
> equal at all. If they are of a different type, then they cannot be
> equal, thus the anwser to "Are 'self' and 'other' equal?" should be
> False. This again, would mean an equal operation is implemented and
> returning NotImplemented is not the right anwser.

The explanation for NotImplemented is that an user-defined class may
decide it can compare equal to a WeakSet (without inheriting from
WeakSet). Returning NotImplemented from WeakSet.__eq__ gives a chance to
the user-defined class' __eq__ method to be called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 17:58:06 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 15 May 2009 15:58:06 +0000
Subject: [issue1200] Allow array.array to be parsed by the t# format unit.
In-Reply-To: <1190697931.82.0.81567230307.issue1200@psf.upfronthosting.co.za>
Message-ID: <1242403086.5.0.0199663106488.issue1200@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I actually have no idea what I was trying to do when I ran into this. I
think it was a use somewhere in the standard libraries rather than my
own code, so if uses of t# are gone from there, I'd have no objections
to closing this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200>
_______________________________________

From report at bugs.python.org  Fri May 15 18:42:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 16:42:07 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242405727.15.0.791893272286.issue5964@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can commit the latest patch, provided all tests pass.

----------
assignee:  -> schuppenies
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Fri May 15 19:06:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 17:06:05 +0000
Subject: [issue2116] weakref copy module interaction
In-Reply-To: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>
Message-ID: <1242407165.72.0.654136514293.issue2116@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r72662, r72670. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2116>
_______________________________________

From report at bugs.python.org  Fri May 15 19:46:25 2009
From: report at bugs.python.org (Douglas Alan)
Date: Fri, 15 May 2009 17:46:25 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1242409585.02.0.949900911428.issue1152248@psf.upfronthosting.co.za>


Douglas Alan <doug at alum.mit.edu> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:

> Nick Coghlan <ncoghlan at gmail.com> added the comment:

> > Note that the problem with the read()+split() approach is that you
> > either have to read the whole file into memory (which this RFE is 
trying
> > to avoid) or you have to do your own buffering and so forth to split
> > records as you go. Since the latter is both difficult to get right 
and
> > very similar to what the IO module already has to do for 
readlines(), it
> > makes sense to include the extra complexity there.

> I wonder how often this use case happens though.

Every day for me.  The reason that I originally brought up this request
some years back on comp.lang.python was that I wanted to be able to use
Python easily like I use the xargs program.

E.g.,

   find -type f -regex 'myFancyRegex' -print0 | stuff-to-do-on-each-
file.py

With "-print0" the line separator is chaged to null, so that you can
deal with filenames that have newlines in them.

("find" and "xargs" traditionally have used newline to separate files,
but that fails in the face of filenames that have newlines in them, so
the -print0 argument to find and the "-0" argument to xargs were
thankfully eventually added as a fix for this issue.  Nulls are not
allowed in filenames.  At least not on Unix.)

> When you don't split on lines, conversely, you probably have a binary
> format,

That's not true for the daily use case I just mentioned.

|>ouglas

P.S. I wrote my own version of readlines, of course, as the archives of
comp.lang.python will show.  I just don't feel that everyone should be
required to do the same, when this is the sort of thing that sysadmins
and other Unix-savy folks are wont to do on a daily basis.

P.P.S. Another use case is that I often end up with files that have
beeen transferred back and forth between Unix and Windows and
god-knows-what-else, and the newlines end up being some weird mixture of
carriage returns and line feeds (and sometimes some other stray
characters such as "=20" or somesuch) that many programs seem to have a
hard time recognizing as newlines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Fri May 15 19:47:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 May 2009 17:47:41 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242409661.22.0.734534889016.issue6028@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Hmm, the interpreter should not crash so easily with pyre Python code.
(The same code correctly raises RuntimeException wich python 2.x)
The issue should be corrected IMO.

The exact behavior seem to depend on where the recursion limit is detected:

- If it is detected at the beginning of the function (at the start of
PyEval_EvalFrameEx) or before the "try" statement, the exception is
correctly propagated and displayed. This case always happens with 2.x,
and you get the same on 3.0 if you add for example str([[[[[[[[]]]]]]]])
at the beginning of the function.

- The crash occurs when the recursion limit is detected while
PyEval_EvalFrameEx calls PyErr_NormalizeException() (in the "why ==
WHY_EXCEPTION" block). This does not change the control flow: the
original exception is simply replaced by the RuntimeError, and nested
calls continue 50 more frames.

Here is a tentative patch.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file13990/stackoverflow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Fri May 15 20:13:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 May 2009 18:13:10 +0000
Subject: [issue5998] Add __bool__ to threading.Event and multiprocessing.Event
In-Reply-To: <1242077059.81.0.31819803999.issue5998@psf.upfronthosting.co.za>
Message-ID: <1242411190.6.0.236965069178.issue5998@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm closing because a lack of positive feedback on the list.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5998>
_______________________________________

From report at bugs.python.org  Fri May 15 21:01:01 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 May 2009 19:01:01 +0000
Subject: [issue5353] Improve IndexError messages with actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1242414061.35.0.679388349142.issue5353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This issue is about formatting a value into an error message.
#1182143 is about adding values that have already been formatted into an
error message to the resulting exception object.  If this suggestion
were implemented, then IndexError would be added to the exceptions
covered by #1182143

Patches to mailing lists tend to get lost.  Thank you for finding
Bjourne's. I have invited him (at the email then given) to update it and
attach it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________

From report at bugs.python.org  Fri May 15 21:17:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 May 2009 19:17:32 +0000
Subject: [issue5353] Improve IndexError messages with actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1242415052.25.0.948049704944.issue5353@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I've seen his patch and am working on my own variant that also attaches
the index value as a separate field in the args tuple.  The problem may
be that it slows down the code -- at first I thought that didn't matter,
but someone made a good effort to make the existing code fast (possibly
to support cases where IndexError is used for control flow instead of
for error conditions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________

From report at bugs.python.org  Fri May 15 21:53:35 2009
From: report at bugs.python.org (kxroberto)
Date: Fri, 15 May 2009 19:53:35 +0000
Subject: [issue5141] C API for appending to arrays
In-Reply-To: <1233654934.43.0.515749486926.issue5141@psf.upfronthosting.co.za>
Message-ID: <1242417215.6.0.242015809323.issue5141@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

I had a similar problem creating a C-fast array.array interface for Cython.
The array.pxd package here (latest zip file)
http://trac.cython.org/cython_trac/ticket/314
includes a arrayarray.h file, which provides ways for efficient creation
and growth from C (extend, extend_buffer, resize, resize_smart ). Its
probably in one of the next Cython distributions anyway, and will be
maintained. And perhaps array2 and arrayM extension subclasses (very
light-weight numpy) with public API coming soon too.
It respects the different Python versions, so its a lite "quasi API".
And in case there will be a (unlikely) change in future Pythons, the
Cython people will take care as far as there is no official API coming up.
Or perhaps most people with such interest use Cython anyway.

----------
nosy: +kxroberto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5141>
_______________________________________

From report at bugs.python.org  Fri May 15 21:53:48 2009
From: report at bugs.python.org (Marc Culler)
Date: Fri, 15 May 2009 19:53:48 +0000
Subject: [issue6015] Tkinter Scrollbar in OS X 10.5
In-Reply-To: <1242255714.91.0.667692922857.issue6015@psf.upfronthosting.co.za>
Message-ID: <1242417228.59.0.400443879011.issue6015@psf.upfronthosting.co.za>


Marc Culler <culler at math.uic.edu> added the comment:

I have the same issues with Python 2.6 code I have written.  In OS X
10.4 the scrollbars work correctly with a Tkinter Text widget.  The same
code running in 10.5 exhibits this erratic behavior.  It appears as
though mouse movement events are queued up, causing the mouse to get
ahead of the scrollbar.  Later, at some random time, it appears as
though the queued events get processed all at once, causing the
scrollbar to leap ahead of the mouse.  The scrollbar widget display also
becomes corrupted at times, with the blue color from the slider being
written into the buttons at the bottom.

----------
components: +Tkinter -IDLE
nosy: +culler
title: Scrollbar in Idle os x 10.5 -> Tkinter Scrollbar in OS X 10.5
type:  -> performance
versions: +Python 2.6 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6015>
_______________________________________

From report at bugs.python.org  Fri May 15 22:23:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 May 2009 20:23:28 +0000
Subject: [issue5975] csv unix file format ('\n' line terminator)
In-Reply-To: <1241821870.32.0.544896440632.issue5975@psf.upfronthosting.co.za>
Message-ID: <1242419008.85.0.693523122361.issue5975@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

New features must be targeted at 2.7/3.2.  2.5 is in security-fix only
mode and 2.6 in bug-fix only mode, as is 3.0.  3.1 is in beta with new
features pretty well frozen.

----------
nosy: +tjreedy
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5975>
_______________________________________

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: [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  Fri May 15 22:27:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 May 2009 20:27:55 +0000
Subject: [issue6030] io.BufferedWriter C module missing _write_lock
In-Reply-To: <1242419104.2.0.221956700453.issue6030@psf.upfronthosting.co.za>
Message-ID: <1242419275.47.0.493981445407.issue6030@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

That's supposed to be a private attribute, so, yes, the omission was
purposeful.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6030>
_______________________________________

From report at bugs.python.org  Fri May 15 22:28:19 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 May 2009 20:28:19 +0000
Subject: [issue5980] Add bug tracker tasks to PEP 101
In-Reply-To: <1241897065.28.0.181996092756.issue5980@psf.upfronthosting.co.za>
Message-ID: <1242419299.7.0.948527253312.issue5980@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Would these tasks, whereever documented, be entirely manual or partly
automated?  I just fixed new feature request #5975 which originally
selected 2.5,2.6,3.0.  It would be nice if the tracker automatically
rejected such invalid selections and selected 2.7/3.2 instead.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5980>
_______________________________________

From report at bugs.python.org  Fri May 15 22:30:19 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 May 2009 20:30:19 +0000
Subject: [issue5980] Add bug tracker tasks to PEP 101
In-Reply-To: <1241897065.28.0.181996092756.issue5980@psf.upfronthosting.co.za>
Message-ID: <1242419419.39.0.10932276151.issue5980@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I of course agree that these tasks should be listed somewhere, but have
no opinion on which PEP, if not both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5980>
_______________________________________

From report at bugs.python.org  Fri May 15 22:38:57 2009
From: report at bugs.python.org (Josh Roesslein)
Date: Fri, 15 May 2009 20:38:57 +0000
Subject: [issue6030] io.BufferedWriter C module missing _write_lock
In-Reply-To: <1242419104.2.0.221956700453.issue6030@psf.upfronthosting.co.za>
Message-ID: <1242419937.84.0.653083756927.issue6030@psf.upfronthosting.co.za>


Josh Roesslein <jroesslein at gmail.com> added the comment:

Okay so even if you extend the BufferedWriter class, you should not
be using that lock for thread safety, correct? But you must still use
locks since its not thread safe still?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6030>
_______________________________________

From report at bugs.python.org  Fri May 15 22:40:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 20:40:05 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242420005.44.0.449668311638.issue6028@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury, your patch might make some individual cases better, but it won't
prevent a FatalError from occurring in all cases.

Also, it makes things worse in the following case:

def recurse():
    try:
        recurse()
    except:
        recurse()
        
recurse()

(the script goes into an uninterruptible infinite loop, rather than
raising an explicit Fatal error)

More useful, IMHO, would be to patch Py_FatalError() so that a traceback
is printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Fri May 15 22:41:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 20:41:21 +0000
Subject: [issue6030] io.BufferedWriter C module missing _write_lock
In-Reply-To: <1242419104.2.0.221956700453.issue6030@psf.upfronthosting.co.za>
Message-ID: <1242420081.46.0.144924121766.issue6030@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The C BufferedWriter class itself is thread-safe. I'm not sure what you
are worried about, perhaps you are writing your own derived class?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6030>
_______________________________________

From report at bugs.python.org  Fri May 15 22:42:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 20:42:24 +0000
Subject: [issue5141] C API for appending to arrays
In-Reply-To: <1233654934.43.0.515749486926.issue5141@psf.upfronthosting.co.za>
Message-ID: <1242420144.24.0.238908822081.issue5141@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This has more chances of seeing some progress if you propose a patch.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5141>
_______________________________________

From report at bugs.python.org  Fri May 15 22:48:54 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 May 2009 20:48:54 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1242420534.12.0.148448882446.issue5982@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Having to bind and unbind a classmethod to get at the function is
definitely a bit weird, and also susceptible to changing implementation,
but do you have a practical use case to motivate the effort needed?

In Py3, '__func__' replaced 'im_func', and that is the name to use if
the attribute is added.  A change in 3.2 is at least as likely as a
change in 2.7.

----------
nosy: +tjreedy
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

From report at bugs.python.org  Fri May 15 22:50:44 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 May 2009 20:50:44 +0000
Subject: [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: <1242420644.44.0.36697607899.issue5985@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

At this point, 2.7/3.2 are the only targets for new features.

----------
nosy: +tjreedy
versions:  -Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Fri May 15 23:37:50 2009
From: report at bugs.python.org (Clifford W Johnson)
Date: Fri, 15 May 2009 21:37:50 +0000
Subject: [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: <1242423470.3.0.00680215147736.issue6029@psf.upfronthosting.co.za>


Changes by Clifford W Johnson <Clifford at IEEE.org>:


----------
nosy: +JohnsonCW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6029>
_______________________________________

From report at bugs.python.org  Fri May 15 23:45:10 2009
From: report at bugs.python.org (Jay Talbot)
Date: Fri, 15 May 2009 21:45:10 +0000
Subject: [issue5975] csv unix file format ('\n' line terminator)
In-Reply-To: <1241821870.32.0.544896440632.issue5975@psf.upfronthosting.co.za>
Message-ID: <1242423910.36.0.604802459507.issue5975@psf.upfronthosting.co.za>


Jay Talbot <jay.talbot at gmail.com> added the comment:

I'm sorry. I will remember to try and look up where the new features are
being targeted. Reporting bugs and requesting new features here is new
to me. Everyone seems to have their own rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5975>
_______________________________________

From report at bugs.python.org  Fri May 15 23:59:38 2009
From: report at bugs.python.org (Clifford W Johnson)
Date: Fri, 15 May 2009 21:59:38 +0000
Subject: [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: <1242424778.55.0.914319622154.issue6029@psf.upfronthosting.co.za>


Clifford W Johnson <Clifford at IEEE.org> added the comment:

I get a nearly identical failure building Python 2.6.2 on a SPARC64
machine running Solaris 5.10 using GCC 4.1.1.

# ./python ./Lib/test/test_ctypes.py
...
test_longdouble (ctypes.test.test_callbacks.Callbacks) ... FAIL
...

======================================================================
FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
    self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1400000000000001)

----------------------------------------------------------------------
Ran 319 tests in 1.951s

FAILED (failures=1)
Traceback (most recent call last):
  File "./Lib/test/test_ctypes.py", line 12, in <module>
    test_main()
  File "./Lib/test/test_ctypes.py", line 9, in test_main
    run_unittest(unittest.TestSuite(suites))
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/test/test_support.py",
line 722, in run_unittest
    _run_suite(suite)
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/test/test_support.py",
line 705, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
    self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1400000000000001)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6029>
_______________________________________

From report at bugs.python.org  Sat May 16 00:54:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 22:54:47 +0000
Subject: [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: <1242428087.95.0.705052962324.issue5956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ouch! Could you try to simply open() an exe file in the interactive
interpreter?
What does os.stat() give on this exe file?
What does os.stat() give on a "real" directory?

If some files are also directories under MacOS X, perhaps we must
reconsider the directory detection routine in _fileio.c.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 00:55:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 22:55:05 +0000
Subject: [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: <1242428105.84.0.327576177751.issue5956@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +IO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 01:11:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 May 2009 23:11:08 +0000
Subject: [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: <1242429068.18.0.88745183918.issue5956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Where does wininst-6.0.1.exe come from? I don't see it on a fresh
checkout (there's only wininst-6.0.exe (without the ".1")). Does MacOS X
create these "aliases" automatically?

Did you install Python 3.1 or are your running directly from the source
tree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 01:57:57 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 15 May 2009 23:57:57 +0000
Subject: [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: [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:07:57 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 01:07:57 +0000
Subject: [issue6032] Fix refleaks in test_urllib2_localnet
In-Reply-To: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>
Message-ID: <1242436077.83.0.767618793335.issue6032@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Collin,
This the fix for issue 6002, right? Does issue 1208304 also cause leaks
in your tests?

----------
dependencies: +test_urllib2_localnet DigestAuthHandler leaks nonces
nosy: +ajaksu2
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6032>
_______________________________________

From report at bugs.python.org  Sat May 16 03:11:44 2009
From: report at bugs.python.org (Collin Winter)
Date: Sat, 16 May 2009 01:11:44 +0000
Subject: [issue6032] Fix refleaks in test_urllib2_localnet
In-Reply-To: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>
Message-ID: <1242436304.1.0.544744801135.issue6032@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Yes, this is a patch for issue 6002 (sorry, didn't find it). I haven't
seen any refleaks from issue 1208304, but I was only looking at this one
particular failure (since it was showing up in Unladen Swallow's refleak
builds).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6032>
_______________________________________

From report at bugs.python.org  Sat May 16 03:13:42 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 01:13:42 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1242436422.66.0.383030878781.issue5677@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +IO
nosy: +benjamin.peterson, pitrou
priority:  -> high
stage:  -> test needed
versions:  -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________

From report at bugs.python.org  Sat May 16 03:14:49 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 01:14:49 +0000
Subject: [issue4188] Lib/threading.py causes infinite recursion when running
	as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1242436489.41.0.402280027387.issue4188@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> high
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4188>
_______________________________________

From report at bugs.python.org  Sat May 16 03:15:43 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 01:15:43 +0000
Subject: [issue4186] type() doesn't accept bases and dict keyword arguments
In-Reply-To: <1224753211.57.0.0760272194538.issue4186@psf.upfronthosting.co.za>
Message-ID: <1242436543.47.0.806742337305.issue4186@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4186>
_______________________________________

From report at bugs.python.org  Sat May 16 03:20:24 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 01:20:24 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1242436824.71.0.757786301251.issue4174@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Given the drawbacks mentioned (and the fact that the current patch would
break when the list mutates under its feet), is this still valid?

----------
nosy: +ajaksu2
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

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: [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:16:43 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 16 May 2009 03:16:43 +0000
Subject: [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: <1242443803.32.0.138169582875.issue5956@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Here are the answers to your questions.

% python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('Lib/distutils/command/wininst-6.0.exe')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 21] Is a directory: 'Lib/distutils/command/wininst-6.0.exe'

>>> import os
>>> os.path.isdir('Lib/distutils/command/wininst-6.0.exe')
True

>>> os.stat('Lib/distutils/command/wininst-6.0.exe')
posix.stat_result(st_mode=16877, st_ino=6314085L, st_dev=234881026L, st_nlink=2, st_uid=501, 
st_gid=501, st_size=68L, st_atime=1242244664, st_mtime=1241712622, st_ctime=1241712622)

>>> os.stat('Lib/distutils/command')
posix.stat_result(st_mode=16877, st_ino=6314060L, st_dev=234881026L, st_nlink=58, st_uid=501, 
st_gid=501, st_size=1972L, st_atime=1242244781, st_mtime=1242245012, st_ctime=1242245012)


But here is the root cause.  The Python-3.1b1 files were created by Stuffit Expander ffrom the original 
Python-3.1b1 tar ball downloaded from the Python website.  Changing the Stuffit preferences does not 
make any difference.  

However, if that same tar ball is uncompressed by the  tar -zxf ... command, there are no directories.  
Only five simple files, as expected:

-rw-r--r--   1 jean  jean   61440 Jul 15  2008 wininst-6.0.exe
-rw-r--r--   1 jean  jean   65536 Jul 15  2008 wininst-7.1.exe
-rw-r--r--   1 jean  jean   61440 Jan 20 13:25 wininst-8.0.exe
-rw-r--r--   1 jean  jean  224256 Jan 29 05:08 wininst-9.0-amd64.exe
-rw-r--r--   1 jean  jean  196096 Jan 29 05:08 wininst-9.0.exe


After removing the directory files (and renaming the *.1.exe to *.exe), the regression tests passes.

% ./python.exe ../Python-3.1b1/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) ... ok
test_build_libraries (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_check_library_dist (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_finalize_options (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_get_source_files (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_solaris_enable_shared (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_user_site (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_empty_package_dir (distutils.tests.test_build_py.BuildPyTestCase) ... ok
test_package_data (distutils.tests.test_build_py.BuildPyTestCase) ... ok
test_build (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... ok
test_default_settings (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... ok
test_version_int (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... ok
test_check_all (distutils.tests.test_check.CheckTestCase) ... ok
test_check_document (distutils.tests.test_check.CheckTestCase) ... ok
test_check_metadata (distutils.tests.test_check.CheckTestCase) ... ok
test_check_restructuredtext (distutils.tests.test_check.CheckTestCase) ... ok
test_simple_run (distutils.tests.test_clean.cleanTestCase) ... ok
test_dump_options (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_dirname (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_filename (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_string (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_string_list (distutils.tests.test_cmd.CommandTestCase) ... ok
test_make_file (distutils.tests.test_cmd.CommandTestCase) ... ok
test_server_empty_registration (distutils.tests.test_config.PyPIRCCommandTestCase) ... ok
test_server_registration (distutils.tests.test_config.PyPIRCCommandTestCase) ... ok
test_clean (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_dump_file (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_finalize_options (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_run_setup_provides_file (distutils.tests.test_core.CoreTestCase) ... ok
test_run_setup_uses_current_dir (distutils.tests.test_core.CoreTestCase) ... ok
test_copy_tree_verbosity (distutils.tests.test_dir_util.DirUtilTestCase) ... ok
test_create_tree_verbosity (distutils.tests.test_dir_util.DirUtilTestCase) ... ok
test_mkpath_remove_tree_verbosity (distutils.tests.test_dir_util.DirUtilTestCase) ... ok
test_command_packages_cmdline (distutils.tests.test_dist.DistributionTestCase) ... ok
test_command_packages_configfile (distutils.tests.test_dist.DistributionTestCase) ... ok
test_command_packages_unspecified (distutils.tests.test_dist.DistributionTestCase) ... ok
test_empty_options (distutils.tests.test_dist.DistributionTestCase) ... ok
test_custom_pydistutils (distutils.tests.test_dist.MetadataTestCase) ... ok
test_obsoletes (distutils.tests.test_dist.MetadataTestCase) ... ok
test_obsoletes_illegal (distutils.tests.test_dist.MetadataTestCase) ... ok
test_provides (distutils.tests.test_dist.MetadataTestCase) ... ok
test_provides_illegal (distutils.tests.test_dist.MetadataTestCase) ... ok
test_requires (distutils.tests.test_dist.MetadataTestCase) ... ok
test_requires_illegal (distutils.tests.test_dist.MetadataTestCase) ... ok
test_simple_metadata (distutils.tests.test_dist.MetadataTestCase) ... ok
test_move_file_verbosity (distutils.tests.test_file_util.FileUtilTestCase) ... ok
test_glob_to_re (distutils.tests.test_filelist.FileListTestCase) ... ok
test_home_installation_scheme (distutils.tests.test_install.InstallTestCase) ... ok
test_user_site (distutils.tests.test_install.InstallTestCase) ... ok
test_simple_run (distutils.tests.test_install_data.InstallDataTestCase) ... ok
test_simple_run (distutils.tests.test_install_headers.InstallHeadersTestCase) ... ok
test_default_settings (distutils.tests.test_install_scripts.InstallScriptsTestCase) ... ok
test_installation (distutils.tests.test_install_scripts.InstallScriptsTestCase) ... ok
test_no_compiler (distutils.tests.test_msvc9compiler.msvc9compilerTestCase) ... ok
test_reg_class (distutils.tests.test_msvc9compiler.msvc9compilerTestCase) ... ok
test_create_pypirc (distutils.tests.test_register.registerTestCase) ... ok
test_password_not_in_file (distutils.tests.test_register.registerTestCase) ... ok
test_password_reset (distutils.tests.test_register.registerTestCase) ... ok
test_registering (distutils.tests.test_register.registerTestCase) ... ok
test_server_empty_registration (distutils.tests.test_register.registerTestCase) ... ok
test_server_registration (distutils.tests.test_register.registerTestCase) ... ok
test_add_defaults (distutils.tests.test_sdist.sdistTestCase) ... ok
test_make_distribution (distutils.tests.test_sdist.sdistTestCase) ... ok
test_prune_file_list (distutils.tests.test_sdist.sdistTestCase) ... ok
test_server_empty_registration (distutils.tests.test_sdist.sdistTestCase) ... ok
test_server_registration (distutils.tests.test_sdist.sdistTestCase) ... ok
test_nt_quote_args (distutils.tests.test_spawn.SpawnTestCase) ... ok
test_customize_compiler (distutils.tests.test_sysconfig.SysconfigTestCase) ... ok
test_get_config_h_filename (distutils.tests.test_sysconfig.SysconfigTestCase) ... ok
test_get_config_vars (distutils.tests.test_sysconfig.SysconfigTestCase) ... ok
test_get_python_inc (distutils.tests.test_sysconfig.SysconfigTestCase) ... ok
test_get_python_lib (distutils.tests.test_sysconfig.SysconfigTestCase) ... ok
test_class (distutils.tests.test_text_file.TextFileTestCase) ... ok
test_finalize_options (distutils.tests.test_upload.uploadTestCase) ... ok
test_saved_password (distutils.tests.test_upload.uploadTestCase) ... ok
test_server_empty_registration (distutils.tests.test_upload.uploadTestCase) ... ok
test_server_registration (distutils.tests.test_upload.uploadTestCase) ... ok
test_upload (distutils.tests.test_upload.uploadTestCase) ... ok
test_change_root (distutils.tests.test_util.utilTestCase) ... ok
test_check_environ (distutils.tests.test_util.utilTestCase) ... ok
test_convert_path (distutils.tests.test_util.utilTestCase) ... ok
test_get_platform (distutils.tests.test_util.utilTestCase) ... ok
test_rfc822_escape (distutils.tests.test_util.utilTestCase) ... ok
test_split_quoted (distutils.tests.test_util.utilTestCase) ... ok
test_strtobool (distutils.tests.test_util.utilTestCase) ... ok
test_cmp (distutils.tests.test_version.VersionTestCase) ... ok
test_cmp_strict (distutils.tests.test_version.VersionTestCase) ... ok
test_prerelease (distutils.tests.test_version.VersionTestCase) ... ok
Doctest: distutils.versionpredicate.VersionPredicate ... ok
Doctest: distutils.versionpredicate.split_provision ... ok

----------------------------------------------------------------------
Ran 97 tests in 2.646s

OK


My apologies for creating this much trouble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

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: [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 05:26:37 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 May 2009 03:26:37 +0000
Subject: [issue5992] spurious space after opening parenthesis when
	auto-completing
In-Reply-To: <1241999810.49.0.16520968517.issue5992@psf.upfronthosting.co.za>
Message-ID: <1242444397.24.0.0762224042077.issue5992@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What system are you using?  On Windows 3.0.1, standard interpreter window,
'h' 'e' '<tab>' prints 'h' 'e' ' ' ' ' (making, with '>>> ', 8 chars.
Which is to say, there is no tab completion.

On IDLE, same brings up box and <tab> <tab> completes to 'help'

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5992>
_______________________________________

From report at bugs.python.org  Sat May 16 05:47:21 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 May 2009 03:47:21 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1242445641.92.0.445913480064.issue5996@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume you claim the dict example to be a bug in relation to "A class
that has a metaclass derived from ABCMeta cannot be instantiated unless
all of its abstract methods and properties are overridden."

There is the same difference with @abstractproperty
Windows, 3.0.1

class C(metaclass=abc.ABCMeta):
	@abc.abstractmethod
	def f(self): return True

class C2(dict,metaclass=abc.ABCMeta):
	@abc.abstractmethod
	def f(self): return True

c2=C2()
print(c2.f())

c=C()
# prints
True
...
TypeError: Can't instantiate abstract class C with abstract methods f

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Sat May 16 06:20:03 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 May 2009 04:20:03 +0000
Subject: [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: <1242447603.58.0.344568939774.issue6017@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The OP reported a real mismatch between doc and behavior.  If the
behavior is not changed, I think the doc should be.  Other implementors,
reading the doc, might think that they do have to write code to track
changes.  From the doc, I thought that CPython did that.

So I suggest changing reopening and changing the doc to say
"Changing the net size of the dictionary while using iteritems() will
raise a RuntimeError."  Same for iterkeys() and itervalues()[sp?]

Or remove the warning, as happened in the Py3 changeover to views, or
was that a mistake?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Sat May 16 06:55:24 2009
From: report at bugs.python.org (Yury)
Date: Sat, 16 May 2009 04:55:24 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242449724.39.0.560840657912.issue6028@psf.upfronthosting.co.za>


Yury <yury.sobolev at gmail.com> added the comment:

The code you posted causes an infinite loop in the 2.x branch as well.
Anyway, I do not see how crashing is a desired result. An infinite loop
means the programmer made a mistake somewhere. A crash means the
interpreter did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sat May 16 07:02:37 2009
From: report at bugs.python.org (soundmurderer)
Date: Sat, 16 May 2009 05:02:37 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1242450157.54.0.972842481084.issue858809@psf.upfronthosting.co.za>


soundmurderer <soundmurderer at gmail.com> added the comment:

I can confirm that --bindir and --libdir are broken in Python 2.6.2,
despite the fact that ./configure --help lists them as helpful options.
 At the very least, ./configure should complain if you're using options
that don't do anything!  That would be the easy fix.

Here is what I am doing:

./configure \
    --prefix=/home/soundmurderer \
    --bindir=/home/soundmurderer/bin/x86_64/Python-2.6.2 \
    --libdir=/home/soundmurderer/lib/x86_64 

OK, now let's see the relevant section of the generated Makefile:

# Install prefix for architecture-independent files
prefix=         /home/soundmurderer/auzilov

# Install prefix for architecture-dependent files
exec_prefix=    ${prefix}

# Install prefix for data files
datarootdir=    ${prefix}/share

# Expanded directories
BINDIR=         $(exec_prefix)/bin
LIBDIR=         $(exec_prefix)/lib
MANDIR=         ${datarootdir}/man
INCLUDEDIR=     ${prefix}/include
CONFINCLUDEDIR= $(exec_prefix)/include
SCRIPTDIR=      $(prefix)/lib

# Detailed destination directories
BINLIBDEST=     $(LIBDIR)/python$(VERSION)
LIBDEST=        $(SCRIPTDIR)/python$(VERSION)
INCLUDEPY=      $(INCLUDEDIR)/python$(VERSION)
CONFINCLUDEPY=  $(CONFINCLUDEDIR)/python$(VERSION)
LIBP=           $(LIBDIR)/python$(VERSION)

So, the --libdir and --bindir flags had no effect on LIBDIR and BINDIR,
and I wind up editing the Makefile by hand to get desired behavior.

----------
nosy: +soundmurderer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Sat May 16 07:56:18 2009
From: report at bugs.python.org (soundmurderer)
Date: Sat, 16 May 2009 05:56:18 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1242453378.64.0.884781958081.issue858809@psf.upfronthosting.co.za>


soundmurderer <soundmurderer at gmail.com> added the comment:

I tried applying nijel's 2.3.2 patch to Python 2.6.2 Makefile.pre.in,
then configure/make/install with --bindir and --libdir flags to
./configure.  It works in terms of producing the correct Makefile with
LIBDIR and BINDIR that I want, but I get problems after the "make
install" step when I launch the Python interpreter.  This is what happens:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Python 2.6.2 (r262:71600, May 15 2009, 22:46:19)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

I can work around bad imports and "could not find libraries" by adding
various subdirs of my desired LIBDIR to PYTHONHOME and PYTHONPATH.  But
the point is -- I thought that a *properly* installed Python
distribution should know where to find its own standard libraries??  I
should not have to hack PYTHONHOME and PYTHONPATH to get my local
install to work... right?

Once upon a time in 2.5.x days, I was able to do a local install using
only ./configure --prefix, and that's it.  No hacking PYTHONHOME or
PYTHONPATH that I recall.

How is the path to stuff like site.py getting encoded in the Python
installation?  Because I suspect that although nijel's patch may work
for generating makefiles that put binaries/libs in the right place, that
encoding step is still getting botched, requiring to manually set
PYTHONHOME and PYTHONPATH as a workaround.

Or maybe I am just confused.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Sat May 16 09:13:59 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 16 May 2009 07:13:59 +0000
Subject: [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: <1242458039.19.0.76801910941.issue6017@psf.upfronthosting.co.za>


Steven D'Aprano <steve at pearwood.info> added the comment:

I agree with Terry Reedy. I'm re-opening it as a documentation bug (if 
I can -- if I can't, I'll just request somebody who can do so).

----------
components:  -Interpreter Core
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Sat May 16 10:24:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 16 May 2009 08:24:30 +0000
Subject: [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: <1242462270.34.0.134207370741.issue5956@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is it possible that Stuffit tries to unpack every compressed file found 
inside the tar file?
the wininst*.exe files are templates for installers. They likely contain  
part of the signature of a ZIP file, and Stuffit would handle them as an 
archive to unpack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 10:24:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:24:54 +0000
Subject: [issue5829] float('1e500') -> inf, complex('1e500') -> ValueError
In-Reply-To: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
Message-ID: <1242462294.93.0.176874453294.issue5829@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch against py3k.  If someone can review this I'll apply
it for 3.1;  otherwise, it can wait until 3.2.

----------
keywords: +patch
priority:  -> normal
stage: test needed -> commit review
versions:  -Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13993/issue5829.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5829>
_______________________________________

From report at bugs.python.org  Sat May 16 10:25:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:25:27 +0000
Subject: [issue5829] float('1e500') -> inf, complex('1e500') -> ValueError
In-Reply-To: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
Message-ID: <1242462327.52.0.550140741168.issue5829@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5829>
_______________________________________

From report at bugs.python.org  Sat May 16 10:33:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:33:36 +0000
Subject: [issue5786] len(reversed([1,2,3])) does not work anymore in 2.6.2
In-Reply-To: <1240070428.04.0.628652917462.issue5786@psf.upfronthosting.co.za>
Message-ID: <1242462816.73.0.241649112347.issue5786@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is it okay with everyone to close this as "wont fix"?  (BTW, is there
some reason that the Resolution field isn't allowed to have an
apostrophe in it?)  There's nothing we can do about 2.6.2;  it appears
2.6.3 wasn't imminent, and as Raymond says it seems disruptive to
switch it back now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5786>
_______________________________________

From report at bugs.python.org  Sat May 16 10:34:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:34:54 +0000
Subject: [issue5786] len(reversed([1,2,3])) does not work anymore in 2.6.2
In-Reply-To: <1240070428.04.0.628652917462.issue5786@psf.upfronthosting.co.za>
Message-ID: <1242462894.13.0.150858717635.issue5786@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5786>
_______________________________________

From report at bugs.python.org  Sat May 16 10:36:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:36:24 +0000
Subject: [issue5864] format(1234.5, '.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1242462984.38.0.988638946924.issue5864@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Eric, any thoughts on whether this should be backported to 2.6 and 3.0?  
It looks like quite a lot of work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________

From report at bugs.python.org  Sat May 16 10:37:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 08:37:30 +0000
Subject: [issue5864] format(1234.5, '.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1242463050.02.0.328561178632.issue5864@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal
versions: +Python 2.6, Python 3.0 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________

From report at bugs.python.org  Sat May 16 10:42:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 08:42:01 +0000
Subject: [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: <1242463321.89.0.861984067163.issue5956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I was fearing some MacOS X-specific "feature" ? la application bundles.
Thanks for reporting the problem anyway :)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 10:48:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 08:48:50 +0000
Subject: [issue5992] spurious space after opening parenthesis when
	auto-completing
In-Reply-To: <1241999810.49.0.16520968517.issue5992@psf.upfronthosting.co.za>
Message-ID: <1242463730.22.0.49792835754.issue5992@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is with readline and rlcompleter enabled.
However, it actually does this with the installed system Python too, so
I fear some system-specific problem (perhaps a buggy readline library).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5992>
_______________________________________

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: [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:05:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 09:05:22 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242449724.39.0.560840657912.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242464840.5380.15.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The code you posted causes an infinite loop in the 2.x branch as well.
> Anyway, I do not see how crashing is a desired result.

I do not see what the "desired result" is in your example. The code is
obviously wrong. Did you get hit by that in production code or is it
just a proof-of-concept?

Also, this is not an actual crash (as in "segmentation fault"). It is
the interpreter /trying to protect itself from a crash/ which would be
caused by a stack overflow, and your code is trying to circumvent that
protection.

The fact that some errors cannot be recovered from is an unavoidable
fact of life. We may try to "fix" this particular case, but it will do
nothing for the more general case, so we might as well not "fix" it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sat May 16 11:07:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 09:07:04 +0000
Subject: [issue5786] len(reversed(
In-Reply-To: <1242462816.73.0.241649112347.issue5786@psf.upfronthosting.co.za>
Message-ID: <1242464943.5380.17.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is it okay with everyone to close this as "wont fix"?  (BTW, is there
> some reason that the Resolution field isn't allowed to have an
> apostrophe in it?)  There's nothing we can do about 2.6.2;  it appears
> 2.6.3 wasn't imminent, and as Raymond says it seems disruptive to
> switch it back now.

Well, the harm is done, unfortunately, and both resolutions have
analogous downsides, so we might indeed close it.

----------
status: pending -> open
title: len(reversed([1,2,3])) does not work anymore in 2.6.2 -> len(reversed(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5786>
_______________________________________

From report at bugs.python.org  Sat May 16 11:11:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 09:11:28 +0000
Subject: [issue5786] len(reversed(
In-Reply-To: <1240070428.04.0.628652917462.issue5786@psf.upfronthosting.co.za>
Message-ID: <1242465088.48.0.240441381592.issue5786@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, answering by e-mail reopened the bug for some unknown reason.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5786>
_______________________________________

From report at bugs.python.org  Sat May 16 11:13:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 09:13:54 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1242465234.93.0.099125081176.issue6033@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you give results of the "richards" benchmark?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6033>
_______________________________________

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: [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 11:21:44 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sat, 16 May 2009 09:21:44 +0000
Subject: [issue6036] Clean up test_posixpath.py
In-Reply-To: <1242465658.7.0.601350758359.issue6036@psf.upfronthosting.co.za>
Message-ID: <1242465704.69.0.132893579776.issue6036@psf.upfronthosting.co.za>


Changes by Philipp Hagemeister <phihag at phihag.de>:


----------
title: test_posixpath.py -> Clean up test_posixpath.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6036>
_______________________________________

From report at bugs.python.org  Sat May 16 12:42:57 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 10:42:57 +0000
Subject: [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: <1242470577.73.0.264419742855.issue6017@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think it would be better to change the documentation to "will
raise a RuntimeError or result in undefined behavior."  It already tells
you not to do this strongly enough.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

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: [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: [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 13:13:36 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 11:13:36 +0000
Subject: [issue6034] Fix object.__reversed__ doc
In-Reply-To: <1242443888.15.0.235862846371.issue6034@psf.upfronthosting.co.za>
Message-ID: <1242472416.47.0.79937083308.issue6034@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r72675.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6034>
_______________________________________

From report at bugs.python.org  Sat May 16 13:14:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 11:14:58 +0000
Subject: [issue6025] documentation of xml.dom.minidom.parse signature is wrong
In-Reply-To: <1242344778.1.0.605292139005.issue6025@psf.upfronthosting.co.za>
Message-ID: <1242472498.85.0.701135439887.issue6025@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r72676.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6025>
_______________________________________

From report at bugs.python.org  Sat May 16 13:19:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 11:19:03 +0000
Subject: [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: <1242472743.53.0.382391299466.issue6009@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree with you, and have removed the deprecation notice in r72677.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6009>
_______________________________________

From report at bugs.python.org  Sat May 16 13:21:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 11:21:40 +0000
Subject: [issue2856] os.listdir doc should mention that Unicode decoding can
	fail
In-Reply-To: <1210814208.45.0.272157928062.issue2856@psf.upfronthosting.co.za>
Message-ID: <1242472900.87.0.464106861472.issue2856@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r72678.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2856>
_______________________________________

From report at bugs.python.org  Sat May 16 13:25:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 11:25:04 +0000
Subject: [issue5987] Broken link to "Curses Programming with Python"
In-Reply-To: <1241981621.95.0.54234756767.issue5987@psf.upfronthosting.co.za>
Message-ID: <1242473104.01.0.34833532207.issue5987@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, we're only maintaining the docs for maintained branches, and 2.5 is
now in security-fix-only status.  I've clarified the "reporting bugs"
document in the current docs now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5987>
_______________________________________

From report at bugs.python.org  Sat May 16 13:32:36 2009
From: report at bugs.python.org (kxroberto)
Date: Sat, 16 May 2009 11:32:36 +0000
Subject: [issue5141] C API for appending to arrays
In-Reply-To: <1233654934.43.0.515749486926.issue5141@psf.upfronthosting.co.za>
Message-ID: <1242473556.63.0.753500517426.issue5141@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

A first thing would be to select a suitable prefix name for the Array
API. Because the Numpy people have 'stolen' PyArray_ instead of staying
home with PyNDArray_ or so ;-)

In case sb goes into this:
Other than PyList_ like stuff and existing members, think for speedy
access (like in Cython array.pxd) a direct resizing, the buffer pointer,
and something handy like this should be directly exposed:

int 
PyArr_ExtendFromBuffer(PyObject *arr, void* stuff, Py_ssize_t items)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5141>
_______________________________________

From report at bugs.python.org  Sat May 16 13:48:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 11:48:28 +0000
Subject: [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: <1242474508.65.0.87532492519.issue6035@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

More information:  gcc-mp-4.4 is GCC 4.4 from macports.  For
some reason the macports version of gcc is having problems, but
not the regular Apple version.

When I compile with gcc-4.2 from Apple, test_poplib.py passes.
When I compile with gcc-4.2 from macports, test_poplib.py fails as above.

Here's a small script, cut down from test_poplib.py, that generates the 
Bus error.  I'm still trying to work out whether the bug is in gcc, 
Python, or libssl.


import socket, ssl
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s)
ssl_sock.connect(('www.verisign.com', 443))
file = ssl_sock.makefile('rb')
file.close()
ssl_sock.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6035>
_______________________________________

From report at bugs.python.org  Sat May 16 13:57:36 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Sat, 16 May 2009 11:57:36 +0000
Subject: [issue6025] documentation of xml.dom.minidom.parse signature is wrong
In-Reply-To: <1242344778.1.0.605292139005.issue6025@psf.upfronthosting.co.za>
Message-ID: <1242475056.91.0.129301276415.issue6025@psf.upfronthosting.co.za>


Philipp Hagemeister <phihag at phihag.de> added the comment:

The patch has been applied to trunk, but not branches/py3k. Sorry for
that, I should really get into the habit of providing patches for both
branches.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6025>
_______________________________________

From report at bugs.python.org  Sat May 16 14:00:02 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 16 May 2009 12:00:02 +0000
Subject: [issue5864] format(1234.5, '.4') gives misleading result
In-Reply-To: <1240918701.29.0.448631018547.issue5864@psf.upfronthosting.co.za>
Message-ID: <1242475202.76.0.835592809755.issue5864@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't see any point in backporting to 3.0 at this point.

While it's definitely a problem in 2.6, it seems like a big change to
make in a bugfix release. I guess I'm +0 on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5864>
_______________________________________

From report at bugs.python.org  Sat May 16 14:32:04 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 16 May 2009 12:32:04 +0000
Subject: [issue6039] cygwin compilers should not check compiler versions
In-Reply-To: <1242471954.24.0.755904874213.issue6039@psf.upfronthosting.co.za>
Message-ID: <1242477124.2.0.511493566224.issue6039@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The cygwincompiler module has many workarounds for problems with cygwin 
and mingw32.

Can you please show where the error is, and what is the error version of 
the tools you use?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6039>
_______________________________________

From report at bugs.python.org  Sat May 16 14:43:12 2009
From: report at bugs.python.org (samwyse)
Date: Sat, 16 May 2009 12:43:12 +0000
Subject: [issue3058] Let SimpleXMLRPCServer pass client_address to called
	functions.
In-Reply-To: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>
Message-ID: <1242477792.73.0.712030105232.issue3058@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

A more general solution would be to pass the RequestHandler instance as
a parameter to the dispatch function.  This would allow the function to
pick out more than just the client address.  To avoid breaking
pre-existing code, this should be made optional, perhaps by adding a
keyword to the register_function method.  Something like this:

  def __init__(...):
    self._include_request = set()
  def register_function(..., include_request=False):
    self._include_request.add(method)

Later, the dispatch function would be invoked like this:
  kwds = {}
  if method in self._include_request:
    kwds.update(request=self)
  [...]
  return self.instance._dispatch(method, params, **kwds)
  [...]
  return func(client_address, *params, **kwds)

----------
nosy: +samwyse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3058>
_______________________________________

From report at bugs.python.org  Sat May 16 14:49:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 May 2009 12:49:26 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1242478166.16.0.824496788052.issue6033@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

With the patch:

Richards benchmark (Python) starting... [<function entry_point at 0x63b430>]
finished.
Total time for 10 iterations: 8.49 secs
Average time per iteration: 848.90 ms

Without:

Richards benchmark (Python) starting... [<function entry_point at 0x637530>]
finished.
Total time for 10 iterations: 10.46 secs
Average time per iteration: 1045.88 ms

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6033>
_______________________________________

From report at bugs.python.org  Sat May 16 15:04:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 May 2009 13:04:00 +0000
Subject: [issue6037] MutableSequence.__iadd__ should return self
In-Reply-To: <1242467148.54.0.030236085026.issue6037@psf.upfronthosting.co.za>
Message-ID: <1242479040.45.0.792659534317.issue6037@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6037>
_______________________________________

From report at bugs.python.org  Sat May 16 15:14:16 2009
From: report at bugs.python.org (Yury)
Date: Sat, 16 May 2009 13:14:16 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242479656.14.0.249471744917.issue6028@psf.upfronthosting.co.za>


Yury <yury.sobolev at gmail.com> added the comment:

I knew that python handles infinite recursion and gracefully errors out,
and I knew that exception chaining was new to 3.0, so I wanted to see if
they would work together. Apparently, they do not. Yet, the code works
fine in the 2.x branch. So, the 3.0 branch introduces a bug. I am not
sure how much clearer I can make this.

The code is in no way trying to circumvent anything. If there is about
to be a stack overflow, an exception show be raised. It should then
float up the stack. This is the desired result. In fact, this is the
only sane result. In an operating system, a program should not be able
to crash the entire system. In X, a client should not be able to crash
the server. Same principle applies here.

I am sorry I simply do not see your point. This seems so obvious. There
is a correct way of handling this error. You can safely recover from it.
If you insist on a general case, I have outlined it above.

I am not terribly thrilled about your attitude of "we might as well
leave it broken." Why bother working on the project at all?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sat May 16 15:35:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 13:35:57 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242480957.57.0.671102470019.issue6028@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

While we seem to disagree on whether this a real bug (and I'll leave it
at that), I'll just stress once again that a "fatal error" is totally
different from an uncontrolled crash like a segmentation fault -- as I
explained and although you don't seem to understand, the "fatal error"
mechanism is there /precisely/ to avoid uncontrolled crashes. Also, your
analogy with processes crashing an X server is flawed. You should be in
control of all the code running in your own program; Python doesn't
offer any mechanism to protect good code from badly written code when
running in the same address space -- any such expectation is misguided.

(for various ways of producing fatal errors, please search for
"Py_FatalError()" in the source tree)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sat May 16 15:43:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 13:43:48 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1242481428.5.0.346218948979.issue1182143@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Beware that making exceptions hold on arbitrary objects increases the
possibility of delayed collection and reference cycles, though.
(especially in trunk where the "current" exception can last after the
end of an except block)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Sat May 16 15:52:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 May 2009 13:52:08 +0000
Subject: [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: <1242481928.14.0.885830057685.issue6017@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The precisionist in me insists that at a minimum 'will' should be changed
to 'may'.  Otherwise either the docs are lying or the implementation
has a bug.

Or perhaps we could add a footnote about the intentionally divergent
behavior of the CPython implementation?

(As Terry pointed out these docs may be used by other implementors as a
prescriptive guide, just as the language reference is.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Sat May 16 15:53:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 13:53:07 +0000
Subject: [issue6025] documentation of xml.dom.minidom.parse signature is wrong
In-Reply-To: <1242344778.1.0.605292139005.issue6025@psf.upfronthosting.co.za>
Message-ID: <1242481987.31.0.625878313238.issue6025@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, you shouldn't :) It will be merged automatically.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6025>
_______________________________________

From report at bugs.python.org  Sat May 16 16:02:42 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 16 May 2009 14:02:42 +0000
Subject: [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: <1242482562.17.0.117639671284.issue6017@psf.upfronthosting.co.za>


Steven D'Aprano <steve at pearwood.info> added the comment:

With respect Georg, given that the behaviour won't be changed, the 
documentation is simply *wrong*. It's not a matter of telling 
people "don't do this" -- somebody, somewhere, is going to rely on the 
documented behaviour. The docs make the clear promise that, and I 
quote, "Using iteritems() while adding or deleting entries in the 
dictionary will raise a RuntimeError", but that's not what happens. 
The actual behaviour is undefined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Sat May 16 16:25:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 14:25:06 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1242483906.9.0.212082820092.issue6033@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Similar results here.
With the patch:

Richards benchmark (Python) starting... [<function entry_point at
0x7fc15b3f5848>]
finished.
Total time for 4 iterations: 1.78 secs
Average time per iteration: 443.90 ms

Without the patch:

Richards benchmark (Python) starting... [<function entry_point at
0x7f8b9fb20848>]
finished.
Total time for 4 iterations: 2.02 secs
Average time per iteration: 503.79 ms

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6033>
_______________________________________

From report at bugs.python.org  Sat May 16 16:41:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 14:41:14 +0000
Subject: [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: <1242484874.05.0.368517106975.issue6035@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6035>
_______________________________________

From report at bugs.python.org  Sat May 16 16:41:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 14:41:44 +0000
Subject: [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: <1242484904.06.0.793325447854.issue6035@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Even stranger is that the crash happens in debug mode, i.e. without
optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6035>
_______________________________________

From report at bugs.python.org  Sat May 16 16:45:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 16 May 2009 14:45:20 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242485120.2.0.00378400984862.issue6028@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> You should be in control of all the code running in your own program
This is not the case with applications that embed Python to provide 
users a way to script the application.
All the usages of Py_FatalError I've seen detect programming errors at 
the C level, or at interpreter startup.
I still take the rule that no python code should be able to crash the 
program unexpectedly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sat May 16 17:18:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 15:18:18 +0000
Subject: [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: <1242487098.34.0.397968500039.issue6017@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I wouldn't call it *wrong* as much as *not the whole truth*.  It is true
that if just one key is added or removed, a RuntimeError will be raised.
 There are probably lots of places in our docs where the whole truth
isn't told, but in a way that works if you do the sensible thing.

In this case I can neither see anyone relying on RuntimeError being
raised (except for dict's own test suite), nor an implementor looking
only at these docs, not the source, to implement one of Python's most
crucial object types.

Anyway, if you find a new wording that isn't too clumsy, I'll change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Sat May 16 17:20:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 May 2009 15:20:41 +0000
Subject: [issue6038] Should collections.Counter check for int?
In-Reply-To: <1242467735.26.0.543140377658.issue6038@psf.upfronthosting.co.za>
Message-ID: <1242487241.38.0.983179351822.issue6038@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6038>
_______________________________________

From report at bugs.python.org  Sat May 16 18:37:43 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 16 May 2009 16:37:43 +0000
Subject: [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: <1242491863.26.0.484097096552.issue5956@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Possible, I do not know and had never seen this before.

Also, I just installed the latest (free) version 13.0.3 (Intel Build 
165) of Stuffit Expander and the problem does *not* occur.  

But the older Stuffit 11.0.2 (Intel Build 627) still creates 2 files for 
each of these wininst-*.exe file, an empty directory called wininst-
X.exe and a file called wininst-X.1.exe.  And only for these particular 
wininst-*.exe files.  For other *.exe files, empry ones, binaries and 
even files named wininst-X.exe, Stuffit 11 creates only the single file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 19:10:19 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 May 2009 17:10:19 +0000
Subject: [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: <1242493819.4.0.74443186235.issue5956@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Another good reason not to install Stuffit or Stuffit Expander.  These 
days OS X expands the standard open formats (i.e. .gz, .zip, .tar, etc) 
all by itself, and there are the standard command line tools as well.  
If you need Stuffit for actual stuffit archives, I think there is (or 
was) a preference in Stuffit Expander and Stuffit so you can restrict 
which formats they should process.

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5956>
_______________________________________

From report at bugs.python.org  Sat May 16 19:33:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 17:33:31 +0000
Subject: [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: <1242495211.01.0.555785485149.issue6035@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm still trying to work out whether the bug is in gcc, 
> Python, or libssl.

It was, of course, none of the above.  It was a PEBCAK error.
I had two versions of openssl:  one from macports and one from
OS X, and I was using the include files from one version and
linking against the other.

Sorry for the noise.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6035>
_______________________________________

From report at bugs.python.org  Sat May 16 19:47:51 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 17:47:51 +0000
Subject: [issue1884] msilib.SetProperty(msilib.PID_CODEPAGE,
	'1252') raises 0x65d = type mismatch
In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za>
Message-ID: <1242496071.75.0.298479510551.issue1884@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1884>
_______________________________________

From report at bugs.python.org  Sat May 16 19:48:21 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 17:48:21 +0000
Subject: [issue1855] Codepage unset in msilib.init_database()
In-Reply-To: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za>
Message-ID: <1242496101.4.0.472377820356.issue1855@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch
priority: normal -> low
stage:  -> test needed
type: resource usage -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1855>
_______________________________________

From report at bugs.python.org  Sat May 16 19:51:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 May 2009 17:51:33 +0000
Subject: [issue6028] Interpreter crashes when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1242496293.91.0.200569839994.issue6028@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, perhaps something like #1195571 should be added.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sat May 16 20:03:22 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 18:03:22 +0000
Subject: [issue2609] Tests fail if ./@test is not writeable
In-Reply-To: <1207846870.93.0.178479630911.issue2609@psf.upfronthosting.co.za>
Message-ID: <1242497002.66.0.209680485331.issue2609@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +r.david.murray
priority:  -> normal
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2609>
_______________________________________

From report at bugs.python.org  Sat May 16 20:18:06 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 18:18:06 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1242497886.73.0.550750453952.issue2931@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ezio.melotti, haypo, loewis
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2931>
_______________________________________

From report at bugs.python.org  Sat May 16 21:35:27 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:35:27 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1242502527.15.0.524456203158.issue3001@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Sat May 16 21:36:24 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:36:24 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1242502584.58.0.924313972017.issue4256@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
keywords: +easy
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Sat May 16 21:36:58 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:36:58 +0000
Subject: [issue1778] SyntaxError.offset sometimes wrong
In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za>
Message-ID: <1242502618.07.0.299381414411.issue1778@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk and py3k.

----------
nosy: +ajaksu2
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778>
_______________________________________

From report at bugs.python.org  Sat May 16 21:37:06 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:37:06 +0000
Subject: [issue1827] svnversion_init() doesn't support svn urls in
	sandbox/trunk
In-Reply-To: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za>
Message-ID: <1242502626.07.0.711158163618.issue1827@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I'm setting as 'behavior' because ISTM that a bogus svnversion making
Python fail to start is a bug.

----------
nosy: +ajaksu2
priority: normal -> low
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1827>
_______________________________________

From report at bugs.python.org  Sat May 16 21:37:10 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:37:10 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1242502630.93.0.0081127681387.issue1838@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk and py3k. Maybe we should treat ctypes segfaults that
don't involve external C code more strictly as bugs?

----------
nosy: +ajaksu2
stage:  -> test needed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Sat May 16 21:37:39 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:37:39 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1242502659.2.0.734312709303.issue1943@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Collin,
Can you test this patch with Unladen Swallow's benchmarks?

----------
components: +Unicode
nosy: +ajaksu2, collinwinter, ezio.melotti, haypo
stage:  -> test needed
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sat May 16 21:37:45 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:37:45 +0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1242502665.95.0.871656187896.issue2027@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Extension Modules, Unicode -Library (Lib)
priority: normal -> low
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
_______________________________________

From report at bugs.python.org  Sat May 16 21:37:56 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:37:56 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1242502676.77.0.52844225193.issue2122@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> high
stage:  -> test needed
versions: +Python 3.1 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Sat May 16 21:38:23 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:38:23 +0000
Subject: [issue2295] cPickle corner case - docs or bug?
In-Reply-To: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za>
Message-ID: <1242502703.71.0.581211927743.issue2295@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2295>
_______________________________________

From report at bugs.python.org  Sat May 16 21:38:32 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:38:32 +0000
Subject: [issue2423] test_smtplib.py no longer butt slow
In-Reply-To: <1205938249.95.0.187788140387.issue2423@psf.upfronthosting.co.za>
Message-ID: <1242502712.23.0.833856520789.issue2423@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

What platform is that? I'm sure I don't get such a long runtime for
test_smtplib on Linux. Maybe this was fixed by changes in socket or
smtplib itself?

----------
nosy: +ajaksu2
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2423>
_______________________________________

From report at bugs.python.org  Sat May 16 21:38:43 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:38:43 +0000
Subject: [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <1242502723.93.0.746756061908.issue2489@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Fergus,
Can you provide a test for the _copy loop bug? IIUC, the spawn change is
an RFE and shouldn't land on the maintenance branches (or 3.1).

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 3.1 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2489>
_______________________________________

From report at bugs.python.org  Sat May 16 21:38:53 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:38:53 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1242502733.94.0.520941890394.issue2528@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Windows
priority:  -> normal
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2528>
_______________________________________

From report at bugs.python.org  Sat May 16 21:39:07 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:39:07 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1242502747.03.0.831736824817.issue2690@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sat May 16 21:39:18 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:39:18 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1242502758.99.0.42527910831.issue2857@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti, haypo
priority:  -> normal
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Sat May 16 21:39:27 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:39:27 +0000
Subject: [issue2921] enable embedding: declare/#define only py* symbols in
	#includes
In-Reply-To: <1211232563.03.0.480695098403.issue2921@psf.upfronthosting.co.za>
Message-ID: <1242502767.56.0.76309180668.issue2921@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Would this break existing code? Are the benefits worth it?

----------
nosy: +ajaksu2
priority:  -> normal
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2921>
_______________________________________

From report at bugs.python.org  Sat May 16 21:39:33 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:39:33 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1242502773.73.0.828748789388.issue2973@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Would HEADER_ASN1_MAC_H or IMPLEMENT_ASN1_ENCODE_FUNCTIONS_const_fname help?

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Sat May 16 21:39:59 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:39:59 +0000
Subject: [issue3030] compiler warning on HP-UX
In-Reply-To: <1212472557.24.0.226147292753.issue3030@psf.upfronthosting.co.za>
Message-ID: <1242502799.81.0.38294094109.issue3030@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> low
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3030>
_______________________________________

From report at bugs.python.org  Sat May 16 21:40:43 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 19:40:43 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>
Message-ID: <1242502843.2.0.846005966527.issue3023@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

From report at bugs.python.org  Sat May 16 21:42:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 19:42:55 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1242502975.54.0.691688898229.issue2122@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Sat May 16 21:47:03 2009
From: report at bugs.python.org (Collin Winter)
Date: Sat, 16 May 2009 19:47:03 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1242503223.88.0.839352671137.issue1943@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Daniel, which patch? freelists2.patch or unialloc4.patch? If these are
targeted py3k (judging by the "Versions" selector above), none of
Unladen Swallow's benchmarks work under 3k (we're focusing on 2.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sat May 16 21:47:55 2009
From: report at bugs.python.org (Alexander Solovyov)
Date: Sat, 16 May 2009 19:47:55 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242503275.2.0.225755880926.issue1424152@psf.upfronthosting.co.za>


Changes by Alexander Solovyov <piranha at piranha.org.ua>:


----------
nosy: +piranha

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sat May 16 21:53:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 19:53:54 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1242503223.88.0.839352671137.issue1943@psf.upfronthosting.co.za>
Message-ID: <1242503752.5358.17.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Daniel, which patch? freelists2.patch or unialloc4.patch? If these are
> targeted py3k (judging by the "Versions" selector above), none of
> Unladen Swallow's benchmarks work under 3k (we're focusing on 2.x).

They target py3k indeed. Also, they need updating (at least the
uniallocX patch which is the interesting part here).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

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: [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  Sat May 16 22:33:02 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:33:02 +0000
Subject: [issue3401] wsgiref can't handle unicode environments
In-Reply-To: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>
Message-ID: <1242505982.37.0.903745150928.issue3401@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3401>
_______________________________________

From report at bugs.python.org  Sat May 16 22:33:03 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:33:03 +0000
Subject: [issue3071] The ValueError raised by failing to unpack sequence
	should have more information.
In-Reply-To: <1213063566.77.0.933941671492.issue3071@psf.upfronthosting.co.za>
Message-ID: <1242505983.83.0.189651037919.issue3071@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

What would happen with infinite iterables?

import itertools 
[foo] = itertools.count()

----------
nosy: +ajaksu2
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.3, Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3071>
_______________________________________

From report at bugs.python.org  Sat May 16 22:33:41 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:33:41 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1242506021.96.0.369063483029.issue3132@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Travis,
Do you think you can contribute for this to actually land in 3.2? Having
a critical issue slipping from 3.0 to 3.3 would be bad...

Does this supersede issue 2395 or is this a subset of that one.?

----------
nosy: +ajaksu2
stage:  -> test needed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat May 16 22:33:50 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:33:50 +0000
Subject: [issue2395] [Py3k] struct module changes of PEP 3118
In-Reply-To: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za>
Message-ID: <1242506030.35.0.217362555469.issue2395@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

We're in 3.1 beta. Can you review the status of this implementation?

----------
dependencies: +implement PEP 3118 struct changes
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2395>
_______________________________________

From report at bugs.python.org  Sat May 16 22:33:57 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:33:57 +0000
Subject: [issue2397] Backport 3.0 struct module changes to 2.6
In-Reply-To: <1205856299.38.0.249134952512.issue2397@psf.upfronthosting.co.za>
Message-ID: <1242506037.33.0.515656161845.issue2397@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This risks missing 2.x if nobody adopts the implementation of PEP 3118
in 3.x: 2.7 might be the last 2.x release.

----------
nosy: +ajaksu2
priority:  -> low
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2397>
_______________________________________

From report at bugs.python.org  Sat May 16 22:34:02 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:34:02 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1242506042.31.0.282621768362.issue3163@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Sat May 16 22:34:11 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:34:11 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1242506051.85.0.93818893941.issue3232@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Sat May 16 22:34:20 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:34:20 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1242506060.47.0.868860949481.issue3243@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat May 16 22:34:29 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:34:29 +0000
Subject: [issue3246] configure: WARNING: sys/socket.h: present but cannot be
	compiled
In-Reply-To: <1214856989.0.0.383145145027.issue3246@psf.upfronthosting.co.za>
Message-ID: <1242506069.24.0.815477074648.issue3246@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

ric,
Can you confirm this for 2.6?

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3246>
_______________________________________

From report at bugs.python.org  Sat May 16 22:34:36 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:34:36 +0000
Subject: [issue3293] incorrect comments for PyObject_ReleaseBuffer
In-Reply-To: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>
Message-ID: <1242506076.38.0.22706750162.issue3293@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Travis,
How should code, comment and PEP be reconciled?

----------
nosy: +ajaksu2
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3293>
_______________________________________

From report at bugs.python.org  Sat May 16 22:35:06 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:35:06 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1242506106.68.0.379910182675.issue3338@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +test_cpickle crash on AMD64 Windows build
priority:  -> normal
versions: +Python 2.6 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Sat May 16 22:35:06 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:35:06 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1242506106.36.0.34891734085.issue3353@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Sat May 16 22:35:13 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:35:13 +0000
Subject: [issue3354] Improve error reporting for the argument parsing API
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1242506113.71.0.282545376201.issue3354@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Sat May 16 22:35:19 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:35:19 +0000
Subject: [issue3356] some tests fail with 'make EXTRA_CFLAGS="-DPy_DEBUG"'
	(test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1242506119.55.0.461346544164.issue3356@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Build
priority: high -> low
title: some tests fail with Py_DEBUG (test_distutils, test_set) -> some tests fail with 'make EXTRA_CFLAGS="-DPy_DEBUG"' (test_distutils, test_set)
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Sat May 16 22:38:10 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:38:10 +0000
Subject: [issue3435] trace.py tries to get coverage data from non Python files
In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
Message-ID: <1242506290.59.0.69081602185.issue3435@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3435>
_______________________________________

From report at bugs.python.org  Sat May 16 22:38:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 20:38:32 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1242506312.74.0.96821570255.issue5380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Uh, a file descriptor returned by openpty() doesn't satisfy S_ISFIFO().
It's just reported as a character device by fstat (st_mode is 0o20666).
Perhaps the best thing is to just let the error propagate, since after
all the user tries to read more bytes than are available.

----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sat May 16 22:41:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 20:41:50 +0000
Subject: [issue3293] incorrect comments for PyObject_ReleaseBuffer
In-Reply-To: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>
Message-ID: <1242506510.45.0.589642793018.issue3293@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

PyObject_ReleaseBuffer() is dead actually.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3293>
_______________________________________

From report at bugs.python.org  Sat May 16 22:43:04 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:43:04 +0000
Subject: [issue3471] PyObject_GetAttr() to get special methods
In-Reply-To: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>
Message-ID: <1242506584.45.0.816015330383.issue3471@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This snippet is fixed (returns False), see issue 2325:

import abc
isinstance(5, abc.ABCMeta)

The general PyObject_GetAttr issue should be reviewed.

----------
components: +Interpreter Core
nosy: +ajaksu2, benjamin.peterson
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3471>
_______________________________________

From report at bugs.python.org  Sat May 16 22:44:47 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:44:47 +0000
Subject: [issue3486] bytes.join does not accept a sequence of bytearrays
In-Reply-To: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>
Message-ID: <1242506687.27.0.497673080848.issue3486@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

How about adding a note on this to 2.6 docs and be done with it?

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3486>
_______________________________________

From report at bugs.python.org  Sat May 16 22:45:37 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:45:37 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
Message-ID: <1242506737.05.0.305616053779.issue3489@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Sat May 16 22:48:09 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:48:09 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1242506889.92.0.0472122700419.issue3451@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +haypo
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sat May 16 22:49:16 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:49:16 +0000
Subject: [issue3527] Py_WIN_WIDE_FILENAMES removal
In-Reply-To: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
Message-ID: <1242506956.73.0.637473492688.issue3527@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Windows
priority:  -> normal
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3527>
_______________________________________

From report at bugs.python.org  Sat May 16 22:55:59 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 20:55:59 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1242507359.2.0.737747616121.issue3532@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Looks like transform/untransform went nowhere?

----------
nosy: +ajaksu2, lemburg
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sat May 16 22:58:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 20:58:05 +0000
Subject: [issue3527] Py_WIN_WIDE_FILENAMES removal
In-Reply-To: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
Message-ID: <1242507485.52.0.526289272646.issue3527@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3527>
_______________________________________

From report at bugs.python.org  Sat May 16 23:00:07 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 21:00:07 +0000
Subject: [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1242507607.5.0.176296563677.issue3541@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk.

----------
nosy: +ajaksu2, jcea
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________

From report at bugs.python.org  Sat May 16 23:12:37 2009
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sat, 16 May 2009 21:12:37 +0000
Subject: [issue2921] enable embedding: declare/#define only py* symbols in
	#includes
In-Reply-To: <1242502767.56.0.76309180668.issue2921@psf.upfronthosting.co.za>
Message-ID: <hbf.20090516x2co@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Daniel Diniz writes:
> Would this break existing code?

Source code?  Not if you use the PYTHON_NAMESPACE_ONLY trick.  Old
programs will receive all old definitions in addition to the new
autoconf symbols, since they didn't #define PYTHON_NAMESPACE_ONLY.

Programs that do #define PYTHON_NAMESPACE_ONLY will lose symbols you
can't offer because you couldn't be bothered to make them independent
of autoconf.  BTW, another "reduced API" variant would be to throw
autoconf-independent symbols out to separate .h files.  #include those
files from the .h files they come from, and document that programs can
#include them instead of Python.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2921>
_______________________________________

From report at bugs.python.org  Sat May 16 23:17:05 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Sat, 16 May 2009 21:17:05 +0000
Subject: [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1242508625.78.0.698469371689.issue3541@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

The test program uses constant memory on my machine. Ubuntu 9.04,
libdb4.7.25-6ubuntu1, python 2.7 trunk.

----------
nosy: +marcin.bachry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________

From report at bugs.python.org  Sat May 16 23:20:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 May 2009 21:20:50 +0000
Subject: [issue5786] len(reversed(
In-Reply-To: <1240070428.04.0.628652917462.issue5786@psf.upfronthosting.co.za>
Message-ID: <1242508850.0.0.211030070198.issue5786@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing.

----------
resolution:  -> wont fix
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5786>
_______________________________________

From report at bugs.python.org  Sat May 16 23:24:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 21:24:00 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1242509040.16.0.178362668137.issue3338@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now that #3640 has been fixed, this bug is probably fixed too (at least
in trunk and py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Sat May 16 23:39:07 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 21:39:07 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1242509947.21.0.744216500537.issue3581@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hmm, is this a bug in uuid._ifconfig_getnode or just a bad test assumption?

----------
nosy: +ajaksu2
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sat May 16 23:39:35 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 21:39:35 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
Message-ID: <1242509975.73.0.262734966429.issue3583@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Sat May 16 23:57:52 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 May 2009 21:57:52 +0000
Subject: [issue3471] PyObject_GetAttr() to get special methods
In-Reply-To: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>
Message-ID: <1242511072.27.0.874915790287.issue3471@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I fixed the PyObject_GetAttr issue in r72690. I've also been working on
fixing the lookup of other special methods. Armin, do you have a list of
methods we should check?

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3471>
_______________________________________

From report at bugs.python.org  Sun May 17 00:03:55 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 22:03:55 +0000
Subject: [issue1694442] Failure to build on AIX 5.3
Message-ID: <1242511435.04.0.715613286407.issue1694442@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
status:  -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1694442>
_______________________________________

From report at bugs.python.org  Sun May 17 00:08:39 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 22:08:39 +0000
Subject: [issue2921] enable embedding: declare/#define only py* symbols in
	#includes
In-Reply-To: <1211232563.03.0.480695098403.issue2921@psf.upfronthosting.co.za>
Message-ID: <1242511719.06.0.55491762022.issue2921@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hallvard,
There is ongoing discussion on separating public and private headers:
http://groups.google.com/group/unladen-swallow/t/f3a89fc723411c49

Also see #2897, #4805, #5748 and #896330 for (sometimes slightly)
related issues.

----------
dependencies: +include structmember.h in Python.h
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2921>
_______________________________________

From report at bugs.python.org  Sun May 17 00:15:00 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 22:15:00 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1242512100.2.0.627659826398.issue3367@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk:
~/trunk-py$ ./configure --with-pydebug --without-pymalloc && make
[...]
~/trunk-py$ valgrind --suppressions=Misc/valgrind-python.supp ./python
==29730== Memcheck, a memory error detector.
[...]
Python 2.7a0 (trunk:72608M, May 16 2009, 17:31:09)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exec ""
==29730== Conditional jump or move depends on uninitialised value(s)
==29730==    at 0x805BF14: parsetok (parsetok.c:193)
==29730==    by 0x805BB96: PyParser_ParseStringFlagsFilenameEx
(parsetok.c:66)
==29730==    by 0x812A0D3: PyParser_ASTFromString (pythonrun.c:1434)
==29730==    by 0x8129B43: PyRun_StringFlags (pythonrun.c:1299)
==29730==    by 0x8101D37: exec_statement (ceval.c:4631)
[...]
[40389 refs]
>>>
[exit]
==29730==
==29730== Conditional jump or move depends on uninitialised value(s)
==29730==    at 0x805BF14: parsetok (parsetok.c:193)
==29730==    by 0x805BCF0: PyParser_ParseFileFlagsEx (parsetok.c:106)
==29730==    by 0x812A214: PyParser_ASTFromFile (pythonrun.c:1462)
==29730==    by 0x812829C: PyRun_InteractiveOneFlags (pythonrun.c:823)
[...]

----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Sun May 17 00:16:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 May 2009 22:16:22 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1242512182.0.0.79303748118.issue3581@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently, a bad test assumption.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sun May 17 00:17:00 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 22:17:00 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1242512220.09.0.112801511758.issue3605@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Sun May 17 00:56:32 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 22:56:32 +0000
Subject: [issue4712] Document pickle behavior for subclasses of dicts/lists
In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za>
Message-ID: <1242514592.71.0.177500518785.issue4712@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
dependencies: +pickle.dumps cannot save instance of dict-derived class that overrides __getattribute__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4712>
_______________________________________

From report at bugs.python.org  Sun May 17 00:57:43 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 16 May 2009 22:57:43 +0000
Subject: [issue3635] pickle.dumps cannot save instance of dict-derived class
	that overrides __getattribute__
In-Reply-To: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>
Message-ID: <1242514663.78.0.495566154536.issue3635@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Is this related to #1730480?

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3635>
_______________________________________

From report at bugs.python.org  Sun May 17 01:28:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 May 2009 23:28:28 +0000
Subject: [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: <1242516508.16.0.784382910705.issue6017@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would be happy enough to change 'will' to 'may'.  There are a lot of
undocumented exception-raising circumstances, and this one already be
undocumented in Py3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

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: [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 03:21:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 May 2009 01:21:58 +0000
Subject: [issue6043] HTMLParseError derivation
In-Reply-To: <1242517802.47.0.808968818979.issue6043@psf.upfronthosting.co.za>
Message-ID: <1242523318.62.0.291114966257.issue6043@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, the new advice to derive from Exception since StandardError is
being removed in Python 3.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6043>
_______________________________________

From report at bugs.python.org  Sun May 17 03:23:21 2009
From: report at bugs.python.org (Carl Johnson)
Date: Sun, 17 May 2009 01:23:21 +0000
Subject: [issue6038] Should collections.Counter check for int?
In-Reply-To: <1242467735.26.0.543140377658.issue6038@psf.upfronthosting.co.za>
Message-ID: <1242523401.71.0.851747690636.issue6038@psf.upfronthosting.co.za>


Carl Johnson <carl at carlsensei.com> added the comment:

Sounds like a job for ABCs.

----------
nosy: +carlj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6038>
_______________________________________

From report at bugs.python.org  Sun May 17 04:15:31 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:15:31 +0000
Subject: [issue3840] if TESTFN == "/tmp/@test", some tests fail
In-Reply-To: <1221157656.48.0.996285676684.issue3840@psf.upfronthosting.co.za>
Message-ID: <1242526531.65.0.960013011011.issue3840@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3840>
_______________________________________

From report at bugs.python.org  Sun May 17 04:16:36 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:16:36 +0000
Subject: [issue3839] wsgi.simple_server resets 'Content-Length' header on
	empty content even if app defined it.
In-Reply-To: <1221156514.39.0.145827705782.issue3839@psf.upfronthosting.co.za>
Message-ID: <1242526596.29.0.45847476043.issue3839@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +pje
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3839>
_______________________________________

From report at bugs.python.org  Sun May 17 04:20:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 May 2009 02:20:12 +0000
Subject: [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: <1242526812.99.0.105726160736.issue6018@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think the idea is that things like FAIL and ERROR are supposed to grab
your attention as opposed to a simple "ok".

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6018>
_______________________________________

From report at bugs.python.org  Sun May 17 04:42:07 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:42:07 +0000
Subject: [issue3693] Obscure array.array error message
In-Reply-To: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>
Message-ID: <1242528127.5.0.788180639434.issue3693@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

FWIW, in trunk the message for unicode strings is the same:
>>> array.array('b', u'fox')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3693>
_______________________________________

From report at bugs.python.org  Sun May 17 04:42:18 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:42:18 +0000
Subject: [issue3876] multiprocessing does not compile on systems which do not
	define sem_timedwait
In-Reply-To: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za>
Message-ID: <1242528138.81.0.586914345252.issue3876@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage:  -> test needed
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3876>
_______________________________________

From report at bugs.python.org  Sun May 17 04:42:26 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:42:26 +0000
Subject: [issue3877] test_fileio fails on OpenBSD 4.4
In-Reply-To: <1221542542.67.0.83676817672.issue3877@psf.upfronthosting.co.za>
Message-ID: <1242528146.29.0.449909345894.issue3877@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Tests -Extension Modules
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3877>
_______________________________________

From report at bugs.python.org  Sun May 17 04:42:42 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:42:42 +0000
Subject: [issue3948] readline steals sigwinch
In-Reply-To: <1222203569.91.0.225970694441.issue3948@psf.upfronthosting.co.za>
Message-ID: <1242528162.66.0.670900829947.issue3948@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

See related(?) issue 3180.

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3948>
_______________________________________

From report at bugs.python.org  Sun May 17 04:42:49 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:42:49 +0000
Subject: [issue3949] curses' sigwinch handler isn't visible from python
In-Reply-To: <1222204708.76.0.512730295083.issue3949@psf.upfronthosting.co.za>
Message-ID: <1242528169.47.0.94481019279.issue3949@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Shish,
Can you provide a short test script? I think this might also be related
to issue 1687125.

----------
dependencies: +readline steals sigwinch
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3949>
_______________________________________

From report at bugs.python.org  Sun May 17 04:42:55 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:42:55 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1242528175.67.0.828877014537.issue4007@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Sun May 17 04:43:02 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:43:02 +0000
Subject: [issue4035] Support bytes for os.exec*()
In-Reply-To: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>
Message-ID: <1242528182.44.0.0737432842557.issue4035@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Library (Lib)
priority:  -> high
type:  -> feature request
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4035>
_______________________________________

From report at bugs.python.org  Sun May 17 04:43:10 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:43:10 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1242528190.15.0.68390713941.issue4036@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Library (Lib)
priority:  -> high
type:  -> feature request
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Sun May 17 04:43:18 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:43:18 +0000
Subject: [issue4080] pyunit - display time of each test case - patch
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1242528198.61.0.531083043974.issue4080@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
components: +Library (Lib), Tests -None
nosy: +michael.foord
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Sun May 17 04:43:27 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:43:27 +0000
Subject: [issue4126] remove not decodable environment variables
In-Reply-To: <1224031525.89.0.11832939128.issue4126@psf.upfronthosting.co.za>
Message-ID: <1242528207.06.0.950835209641.issue4126@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +loewis
priority:  -> high
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4126>
_______________________________________

From report at bugs.python.org  Sun May 17 04:43:33 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:43:33 +0000
Subject: [issue4144] 3 tutorial documentation errors
In-Reply-To: <1224362134.12.0.593423230728.issue4144@psf.upfronthosting.co.za>
Message-ID: <1242528213.09.0.674171889335.issue4144@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

David,
I hope others can understand your report, I get dizzy looking at it :)

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +ajaksu2, georg.brandl
priority:  -> normal
type:  -> behavior
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4144>
_______________________________________

From report at bugs.python.org  Sun May 17 04:55:21 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 17 May 2009 02:55:21 +0000
Subject: [issue5980] Add bug tracker tasks to PEP 101
In-Reply-To: <1241897065.28.0.181996092756.issue5980@psf.upfronthosting.co.za>
Message-ID: <1242528921.19.0.324603939879.issue5980@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

We sure could have helpers for updating RFEs and bugs to correct
versions. They could be scripts for bulk updating and/or per-issue UI
shortcuts for Developers. I'll open a meta-tracker RFE for this.

Correcting user reports and requests is also possible, but I'd like to
work on help tooltips and maybe a bug report/RFE wizard first: I'm
afraid that on the absence of good explanations/tips, such corrections
might annoy and discourage reporters. Anyway, I"ll open a ticket for
this too :)

Thanks for the feedback!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5980>
_______________________________________

From report at bugs.python.org  Sun May 17 04:58:30 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 May 2009 02:58:30 +0000
Subject: [issue6038] Should collections.Counter check for int?
In-Reply-To: <1242467735.26.0.543140377658.issue6038@psf.upfronthosting.co.za>
Message-ID: <1242529110.54.0.0704269438298.issue6038@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

No thanks.  I'm happy with the API as-is.  It is a consenting adult
tool, simply a dictionary that automatically fills-in missing values
with zero. 

There's no reason to slow it down to a crawl with integer checks at
every step.  Besides, there are some valid use cases with floating point
adjustments.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6038>
_______________________________________

From report at bugs.python.org  Sun May 17 05:11:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 May 2009 03:11:36 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
Message-ID: <1242529896.78.0.602055813408.issue3489@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am -1 on this.  Rotating byte arrays has very few use cases and the ones
it does have can typically be met by indexing.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Sun May 17 05:16:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 May 2009 03:16:16 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1242530176.31.0.0186956296463.issue2690@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sun May 17 05:18:02 2009
From: report at bugs.python.org (aletornw)
Date: Sun, 17 May 2009 03:18:02 +0000
Subject: [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 05:18:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 May 2009 03:18:26 +0000
Subject: [issue6037] MutableSequence.__iadd__ should return self
In-Reply-To: <1242467148.54.0.030236085026.issue6037@psf.upfronthosting.co.za>
Message-ID: <1242530306.12.0.0831311752538.issue6037@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur.  Will fix.

----------
priority:  -> critical
versions: +Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6037>
_______________________________________

From report at bugs.python.org  Sun May 17 07:07:49 2009
From: report at bugs.python.org (Collin Winter)
Date: Sun, 17 May 2009 05:07:49 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1242536869.46.0.776942123454.issue6042@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Sun May 17 07:33:35 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 17 May 2009 05:33:35 +0000
Subject: [issue1738179] help() can't find right source file
Message-ID: <1242538415.18.0.888359141314.issue1738179@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

This is an invalid bug.

python -m 'compileall' -d pdir actdir

all the files in the actdir will be compiled and it will appear as
though the files are getting compiled from pdir. That is the intended
purpose of the -d switch, as I can see from the sourcecode and from the
definition.

So, when you are using inspect module to do inspect.getfile(func_obj),
it would return filename as pdir/filename.py 

To get the actual file, you might want to do inspect.getabsfile(func_obj)

Closing this bug as Invalid.

----------
nosy: +orsenthil
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738179>
_______________________________________

From report at bugs.python.org  Sun May 17 07:39:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 05:39:51 +0000
Subject: [issue3527] Py_WIN_WIDE_FILENAMES removal
In-Reply-To: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
Message-ID: <1242538791.37.0.821120819518.issue3527@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, committed in r72698(trunk) and r72701(py3k).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3527>
_______________________________________

From report at bugs.python.org  Sun May 17 07:40:08 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 17 May 2009 05:40:08 +0000
Subject: [issue1738179] help() can't find right source file
Message-ID: <1242538808.51.0.105037609061.issue1738179@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738179>
_______________________________________

From report at bugs.python.org  Sun May 17 07:42:53 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 05:42:53 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1242538973.12.0.799576512812.issue4856@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Sun May 17 08:18:28 2009
From: report at bugs.python.org (test157@smail.ee)
Date: Sun, 17 May 2009 06:18:28 +0000
Subject: [issue808164] socket.close() doesn't play well with __del__
Message-ID: <1242541108.09.0.991031957602.issue808164@psf.upfronthosting.co.za>


test157 at smail.ee <test157 at smail.ee> added the comment:

The same is happened when you are trying to close pycurl handler at
__del__ method.

----------
nosy: +test157
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/issue808164>
_______________________________________

From report at bugs.python.org  Sun May 17 10:15:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:15:47 +0000
Subject: [issue4144] 3 tutorial documentation errors
In-Reply-To: <1224362134.12.0.593423230728.issue4144@psf.upfronthosting.co.za>
Message-ID: <1242548147.5.0.280303760986.issue4144@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I fixed the three docs issues in r72703 and r72704.  The doctest "issue"
is not an issue; the single backslash is already removed by Python's
tokenizer, so that doctest only sees 'doesn't' which is obviously a
syntax error.  You need to duplicate the backslash, or use a raw docstring.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4144>
_______________________________________

From report at bugs.python.org  Sun May 17 10:21:59 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 17 May 2009 08:21:59 +0000
Subject: [issue6002] test_urllib2_localnet DigestAuthHandler leaks nonces
In-Reply-To: <1242081235.08.0.896974873294.issue6002@psf.upfronthosting.co.za>
Message-ID: <1242548519.13.0.297229802886.issue6002@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6002>
_______________________________________

From report at bugs.python.org  Sun May 17 10:24:55 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:24:55 +0000
Subject: [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: <1242548695.83.0.935774238486.issue6017@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I now changed it to "may raise ... or fail to iterate over all
entries" in r72708.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6017>
_______________________________________

From report at bugs.python.org  Sun May 17 10:32:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:32:27 +0000
Subject: [issue5951] email.message : get_payload args's documentation is
	confusing
In-Reply-To: <1241653521.65.0.301941900122.issue5951@psf.upfronthosting.co.za>
Message-ID: <1242549147.08.0.677225765227.issue5951@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Will be fixed along with all other such instances.

----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5951>
_______________________________________

From report at bugs.python.org  Sun May 17 10:36:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:36:18 +0000
Subject: [issue5942] Ambiguity in dbm.open flag documentation
In-Reply-To: <1241531904.72.0.756438187813.issue5942@psf.upfronthosting.co.za>
Message-ID: <1242549378.32.0.639927246515.issue5942@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think you meant anydbm?  It's already documented well for dbm.open --
I've copied over that table to anydbm in r72710.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5942>
_______________________________________

From report at bugs.python.org  Sun May 17 10:41:22 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 08:41:22 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242549682.08.0.573082695779.issue6012@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> Modifying convert_to_unicode is incorrect; this function is not an O&
> converter. Instead, PyUnicode_FSConverter needs to change.

Well, convert_to_unicode used to use O& before, and I fixed memory leak
with O formatter in current way. I used this function because I know
about it more than PyUnicode_FSConverter. Sorry for confusion. ;-)

> Attached is a patch that does that, and also uses the O& approach. It
> also adjusts the patch to use capsules.

Oh, this is how to use new capsule functions.... I noticed capsule.c was
added, but I didn't know how to use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

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: [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:47:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:47:13 +0000
Subject: [issue5937] Problems with dbm documentation
In-Reply-To: <1241497158.05.0.293072104971.issue5937@psf.upfronthosting.co.za>
Message-ID: <1242550033.76.0.0859422490443.issue5937@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Superseded by #6045.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Fix dbm interfaces

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5937>
_______________________________________

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: [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 10:55:06 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 08:55:06 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242550506.18.0.743891959639.issue6046@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is translated version.

test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... foo.c
   Library
c:\docume~1\whiter~1\locals~1\temp\tmpzdhkyv\tempt\docume~1\whiter~1\l
ocals~1\temp\tmpkhvw2m\foo.lib and object
c:\docume~1\whiter~1\locals~1\temp\tmp
zdhkyv\tempt\docume~1\whiter~1\locals~1\temp\tmpkhvw2m\foo.exp ????
CVPACK : fatal error CK1003: File
c:\docume~1\whiter~1\locals~1\temp\tmpb4w8fe\f
oo.exe cannot be opened
LINK : warning LNK4027: CVPACK error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Sun May 17 10:55:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 08:55:10 +0000
Subject: [issue5935] Better documentation of use of BROWSER environment
	variable
In-Reply-To: <1241489630.51.0.91257880678.issue5935@psf.upfronthosting.co.za>
Message-ID: <1242550510.07.0.377128428941.issue5935@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r72712.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5935>
_______________________________________

From report at bugs.python.org  Sun May 17 10:56:01 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 08:56:01 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242550561.54.0.126045088134.issue6046@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is translated version.

test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... foo.c
   Library
c:\docume~1\whiter~1\locals~1\temp\tmpzdhkyv\tempt\docume~1\whiter~1\l
ocals~1\temp\tmpkhvw2m\foo.lib and object
c:\docume~1\whiter~1\locals~1\temp\tmp
zdhkyv\tempt\docume~1\whiter~1\locals~1\temp\tmpkhvw2m\foo.exp is being
created
CVPACK : fatal error CK1003: File
c:\docume~1\whiter~1\locals~1\temp\tmpb4w8fe\f
oo.exe cannot be opened
LINK : warning LNK4027: CVPACK error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Sun May 17 10:56:12 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 08:56:12 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242550572.0.0.0931022774555.issue6046@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Sun May 17 11:21:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 09:21:07 +0000
Subject: [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: <1242552067.21.0.0780606978428.issue6044@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That no unambiguous conversion between complex and int is defined is
exactly the reason for this error message.  You could want the absolute
value, the real part, the imaginary part, or even the polar angle...

int(abs(z)) works as intended, giving you the absolute value of the
complex number, which is 1 for 1j**2.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6044>
_______________________________________

From report at bugs.python.org  Sun May 17 11:24:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 09:24:18 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1242552258.64.0.177907728294.issue6042@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Jeffrey, while you're at lnotab stuff, could you have a look at #1689458
as well?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Sun May 17 11:49:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 May 2009 09:49:31 +0000
Subject: [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: <1242553771.2.0.790209657302.issue6044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I always found the "use int(abs(z))" part of that message odd,
as well.  As Georg points out, there are many possible ways that
one might want to convert complex to int;  it seems strange to
give advice for one particular one when that may well not match
what the user wanted.

I'd suggest just dropping the "use int(abs(z))" from the error message.
I think it's more likely to be confusing than helpful.

The same applies to float(complex).

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6044>
_______________________________________

From report at bugs.python.org  Sun May 17 12:15:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 10:15:34 +0000
Subject: [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: <1242555334.92.0.839047695316.issue6023@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already done in Sphinx trunk, and will be used for Python as
soon as it is released.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6023>
_______________________________________

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: [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 report at bugs.python.org  Sun May 17 12:35:28 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 10:35:28 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242556528.07.0.207263125265.issue6046@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Ah, well, if this runs on VC9, I think you don't have to worry about
VC6. (VC6 is too old) Of course, I'm happy if this runs on VC6 too.

Anyway, there is msvc9compiler.py, so maybe does different code run on
between VC9 and VC8(or elder)?

I don't know about buildbot slave.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Sun May 17 12:36:06 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 May 2009 10:36:06 +0000
Subject: [issue5514] Darwin framework libpython3.0.a is not a normal static
	library
In-Reply-To: <1237417615.01.0.58676676944.issue5514@psf.upfronthosting.co.za>
Message-ID: <1242556566.4.0.513477554418.issue5514@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Jack: could you please explain what the issue is? Unless you do so I 
will close this issue as "won't fix".

In particular: will linking with "-lpython3.0" work with this 
hypothetical future version of Xcode you're talking about? 

As mentioned before "libpythonX.Y.a" is present for compatibility with a 
number of popular 3th-party tools that have manually written makefiles 
that expect this library to be present. Making the file a symlink to the 
actual dylib in the framework seems to work as intented as the moment: 
the executable gets linked to the framework (just as if it was linked 
with "-framework Python")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5514>
_______________________________________

From report at bugs.python.org  Sun May 17 12:36:29 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 May 2009 10:36:29 +0000
Subject: [issue5514] Darwin framework libpython3.0.a is not a normal static
	library
In-Reply-To: <1237417615.01.0.58676676944.issue5514@psf.upfronthosting.co.za>
Message-ID: <1242556589.48.0.461797579308.issue5514@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5514>
_______________________________________

From report at bugs.python.org  Sun May 17 12:39:06 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 May 2009 10:39:06 +0000
Subject: [issue5766] Mac/scripts/BuildApplet.py reset of sys.executable during
	install can cause it to use wrong modules
In-Reply-To: <1239840739.74.0.413438515887.issue5766@psf.upfronthosting.co.za>
Message-ID: <1242556746.28.0.354452075179.issue5766@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I haven't looked in this particular problem yet, but please note that the 
Mac-specific libraries do not work with an UCS4 build of python.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5766>
_______________________________________

From report at bugs.python.org  Sun May 17 12:49:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 May 2009 10:49:27 +0000
Subject: [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: <1242557367.03.0.896276512484.issue6044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Removed "; use int(abs(z))" from the error message (and the
corresponding pieces from the error messages for long(z)
and float(z)) in r72718, r72719, r72720, r72722.

(Georg agreed to this change in a brief discussion on IRC.)

----------
resolution: invalid -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6044>
_______________________________________

From report at bugs.python.org  Sun May 17 13:00:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 11:00:57 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242558057.15.0.573295108461.issue6046@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

It seems there is two workarounds.

1. remove /pdb:None from linker arguments.
2. Add extension to output filename. (like attached patch)

Maybe, if there is /pdb:None in linker arguments and output filename
doesn't have extension, link.exe may think it has default extension
".exe". I'm not sure.

----------
keywords: +patch
Added file: http://bugs.python.org/file13998/investigate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Sun May 17 13:07:18 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 May 2009 11:07:18 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242558438.35.0.149762324377.issue6012@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, please see r65745. That was O& before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Sun May 17 13:28:48 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 17 May 2009 11:28:48 +0000
Subject: [issue4080] pyunit - display time of each test case - patch
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1242559728.02.0.309195958564.issue4080@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Needs test and documentation. Otherwise looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Sun May 17 13:33:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 11:33:27 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1242560007.47.0.980844872261.issue6045@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

First, lowering priority.

> 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.

Supporting only __getitem__, __setitem__, __delitem__, __contains__ and
keys is already "most of a dict-style interface"?  Only dumbdbm and
bsddb, which isn't in the core anymore, support more methods.

> 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.

It should first be decided what a "dict-style interface" means in Python
3, then I can document it :)

However, for the dbm modules I would be in favor of only specifying the
four mentioned methods, as in the docstring of dbm/__init__.py, and not
claiming any more.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

From report at bugs.python.org  Sun May 17 14:07:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 May 2009 12:07:09 +0000
Subject: [issue3877] test_fileio fails on OpenBSD 4.4
In-Reply-To: <1221542542.67.0.83676817672.issue3877@psf.upfronthosting.co.za>
Message-ID: <1242562029.45.0.557438600192.issue3877@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are other changed files than just test_fileio.py in your patch, I
suppose they aren't needed for this bug?
Also, it would probably be more future-proof to test for `'bsd' in
sys.platform`.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3877>
_______________________________________

From report at bugs.python.org  Sun May 17 14:15:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 May 2009 12:15:10 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1242562510.63.0.838845133048.issue6045@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would inheriting from MutableMapping fix this problem?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

From report at bugs.python.org  Sun May 17 16:02:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 May 2009 14:02:37 +0000
Subject: [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: <1242568957.07.0.434963972377.issue6047@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't understand. fullinstall still overwrites python to link to python3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6047>
_______________________________________

From report at bugs.python.org  Sun May 17 16:17:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 May 2009 14:17:04 +0000
Subject: [issue1738179] help() can't find right source file
Message-ID: <1242569824.97.0.117505934547.issue1738179@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738179>
_______________________________________

From report at bugs.python.org  Sun May 17 18:20:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 May 2009 16:20:45 +0000
Subject: [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: <1242577245.61.0.4517808263.issue6047@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Sorry about the noise, I mustn't have been awake this morning :-(

The fact that fullinstall still creates a "python" executable confuses me 
a little though, I thought the consesus at the language summit at Pycon 
was that we shouldn't do that but only have a "python3" executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6047>
_______________________________________

From report at bugs.python.org  Sun May 17 19:00:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 17:00:39 +0000
Subject: [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: <1242579639.94.0.210848198277.issue6047@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

fullinstall should be removed -- I have the same recollection as Ronald,
so if someone really wants python == python3, he can create the link
himself.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6047>
_______________________________________

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: [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  Sun May 17 21:12:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 May 2009 19:12:51 +0000
Subject: [issue6049] str.strip() and " behaviour expected?
In-Reply-To: <1242586136.29.0.143891828835.issue6049@psf.upfronthosting.co.za>
Message-ID: <1242587571.24.0.537131989985.issue6049@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, it is expected.
When you call .strip() without args it strips the whitespaces, when you
call with an arg it strips only what you specified.
In this example:
>>> s.strip('"')
' "Peter'
the left " is not removed because there's a space in between, in this
example:
>>> s.strip().strip('"')
'Peter'
you first remove the space and then the two ".

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6049>
_______________________________________

From report at bugs.python.org  Sun May 17 21:30:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 May 2009 19:30:41 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1242588641.27.0.560292121746.issue3366@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file10983/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sun May 17 22:51:30 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 17 May 2009 20:51:30 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242593490.25.0.596064125974.issue6046@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

The patch issue5977-w32.patch from issue 5977 has to fix this.
The patch just add suffix for target binary, i.e. on linux target will
become foo.so and on w32 foo.pyd. Note .pyd is correct sugfxi for w32.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Sun May 17 22:55:42 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 17 May 2009 20:55:42 +0000
Subject: [issue5829] float('1e500') -> inf, complex('1e500') -> ValueError
In-Reply-To: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
Message-ID: <1242593742.36.0.156006968014.issue5829@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It looks good to me.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5829>
_______________________________________

From report at bugs.python.org  Sun May 17 23:24:26 2009
From: report at bugs.python.org (Jim Wilson)
Date: Sun, 17 May 2009 21:24:26 +0000
Subject: [issue1855] Codepage unset in msilib.init_database()
In-Reply-To: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za>
Message-ID: <1242595466.46.0.481068706197.issue1855@psf.upfronthosting.co.za>


Jim Wilson <wilson at afn.org> added the comment:

It's been more than a year.  I'll work a little longer on the
SetProperty(...) example, but here's the "confirming evidence".

A related problem is 1884, but I simply don't remember the context and
long ago deleted the code in disgust.

----------
Added file: http://bugs.python.org/file13999/foo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1855>
_______________________________________

From report at bugs.python.org  Sun May 17 23:34:44 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 17 May 2009 21:34:44 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242596084.12.0.26952100999.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Attached is another version of the Modules/_lsprof.c source file.

This _lsprof3.c uses the hires time base on Mac OS X, Solaris and HP-UX 
(plus MS Windows like before) and does not require any asm code.

Also, there are no changes other than the very top of the file.  The 
forward diff with rev 66700 from the trunk is included.

----------
Added file: http://bugs.python.org/file14000/hires_lsprof3.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Sun May 17 23:44:58 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 17 May 2009 21:44:58 +0000
Subject: [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: <1242596698.5.0.83368308008.issue6022@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

After lets call it "cd temp dir" modification the fail on my linux box :
missing libpithon2.7.
What is the buildbot trick as the test pass on all linux buildbots ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From report at bugs.python.org  Sun May 17 23:49:02 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 17 May 2009 21:49:02 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242596942.72.0.697712525441.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Attached is yet another version of the Modules/_lsprof.c source, called 
_lsprof4.c.

This one adds support for the hires timer on 32- and 64-bit Intel and 
PowerPC processors iff compiled with GNU C.

With _lsprof4.c, the high precision profile is available on Linux, Mac 
OS X, Solaris, HP-UX and MS Windows.

Included is the forward diff with _lsprof.c rev 66700 from the trunk.  
The changes are only at the very top and in the initialization function 
at the bottom.

----------
Added file: http://bugs.python.org/file14001/hires_lsprof4.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Sun May 17 23:59:02 2009
From: report at bugs.python.org (Jim Wilson)
Date: Sun, 17 May 2009 21:59:02 +0000
Subject: [issue1884] msilib.SetProperty(msilib.PID_CODEPAGE,
	'1252') raises 0x65d = type mismatch
In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za>
Message-ID: <1242597542.81.0.896098547756.issue1884@psf.upfronthosting.co.za>


Jim Wilson <wilson at afn.org> added the comment:

I hope this helps.  It's Greek to me now.

----------
Added file: http://bugs.python.org/file14002/bar.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1884>
_______________________________________

From report at bugs.python.org  Mon May 18 00:07:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 22:07:27 +0000
Subject: [issue5980] Add bug tracker tasks to PEP 101
In-Reply-To: <1241897065.28.0.181996092756.issue5980@psf.upfronthosting.co.za>
Message-ID: <1242598046.99.0.313730933796.issue5980@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r72756.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5980>
_______________________________________

From report at bugs.python.org  Mon May 18 00:11:15 2009
From: report at bugs.python.org (Jim Wilson)
Date: Sun, 17 May 2009 22:11:15 +0000
Subject: [issue1884] msilib.SetProperty(msilib.PID_CODEPAGE,
	'1252') raises 0x65d = type mismatch
In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za>
Message-ID: <1242598275.32.0.445282961586.issue1884@psf.upfronthosting.co.za>


Jim Wilson <wilson at afn.org> added the comment:

Well, I violated the admonition of the Great Satan: "PID_CODEPAGE must
be first." (or words to that effect).  It turns out not to make a
difference.  Revised (conforming) source attached.

----------
Added file: http://bugs.python.org/file14003/bar.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1884>
_______________________________________

From report at bugs.python.org  Mon May 18 01:31:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 May 2009 23:31:13 +0000
Subject: [issue4215] Running Python 2.6 GUI on Windows Vista
In-Reply-To: <1225149508.54.0.581976390408.issue4215@psf.upfronthosting.co.za>
Message-ID: <1242603073.7.0.543909005492.issue4215@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4215>
_______________________________________

From report at bugs.python.org  Mon May 18 02:17:20 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 May 2009 00:17:20 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242605840.78.0.918492951655.issue6046@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Roumen, your patch worked fine.

----------------------------------------------------------------------
Ran 115 tests in 53.207s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Mon May 18 02:18:30 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 18 May 2009 00:18:30 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242605910.92.0.239938236069.issue5964@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Fixed in r72751.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Mon May 18 03:13:30 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 01:13:30 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242609210.26.0.353002386818.issue2281@psf.upfronthosting.co.za>


Changes by Jean Brouwers <MrJean1 at Gmail.com>:


Removed file: http://bugs.python.org/file14001/hires_lsprof4.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Mon May 18 03:16:53 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 01:16:53 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242609413.29.0.421939633366.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

There were two problems with _lsprof4.c.  Attached is the corrected file 
and the forward diff with _lsprof.c rev 6670.

----------
Added file: http://bugs.python.org/file14004/hires_lsprof4.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Mon May 18 05:50:21 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 18 May 2009 03:50:21 +0000
Subject: [issue5942] Ambiguity in dbm.open flag documentation
In-Reply-To: <1241531904.72.0.756438187813.issue5942@psf.upfronthosting.co.za>
Message-ID: <1242618621.49.0.575697084723.issue5942@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

No, I mean dbm.open. The third paragraph of its documentation says "'c'
to create the database if it doesn?t exist, or 'n', which will always
create a new empty database". This could easily be read as opening the
database just for writing, although come to think of it a write-only
database doesn't make any sense. I guess I was just being
literal/mechanical in my reading of it, trying to make sure it erased
all doubt. If the previous flags hadn't been explicitly documented as
"for reading only" and "for reading and writing" it wouldn't have
occurred to me that 'c' and 'n' should also be documented as reading and
writing. No problem if you think this is too trivial and unlikely a
problem to bother correcting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5942>
_______________________________________

From report at bugs.python.org  Mon May 18 07:01:47 2009
From: report at bugs.python.org (Joe Amenta)
Date: Mon, 18 May 2009 05:01:47 +0000
Subject: [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 07:10:04 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 18 May 2009 05:10:04 +0000
Subject: [issue3003] sys.stdin.fileno() gives attribute error in IDLE
In-Reply-To: <1212079435.96.0.611621924039.issue3003@psf.upfronthosting.co.za>
Message-ID: <1242623404.39.0.204248095894.issue3003@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

>>> type(sys.stdin)
<class 'idlelib.rpc.RPCProxy'>

Don't attempt  sys.stdin._RPCProxy_methods lest you be turned to 
stone ;-)

We didn't implement all the features of stdin as it didn't seem 
necessary.  Did you have a specific reason to access 
stdin.fileno() ?

stdin/out/err support communications between the subprocess and 
the IDLE GUI through a socket.  They are redirected in the GUI and 
proxied in the subprocess.

----------
assignee:  -> kbk
nosy: +kbk
resolution:  -> works for me
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3003>
_______________________________________

From report at bugs.python.org  Mon May 18 07:59:03 2009
From: report at bugs.python.org (chrisyco)
Date: Mon, 18 May 2009 05:59:03 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1242626342.87.0.323406121209.issue4566@psf.upfronthosting.co.za>


chrisyco <chrisyco at gmail.com> added the comment:

After some Googling, I found a possible solution:

http://lists.wxwidgets.org/pipermail/wxpython-users/2008-November/081981.html

----------
nosy: +chrisyco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Mon May 18 08:27:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 May 2009 06:27:10 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242628029.92.0.224027950289.issue6046@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> It would be great to have buildbot making regression tests
> over all compiler flavors.

Yes, I hope snakebite.org will enable us to access to several MSVC
compilers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From report at bugs.python.org  Mon May 18 08:33:29 2009
From: report at bugs.python.org (Bobby Impollonia)
Date: Mon, 18 May 2009 06:33:29 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1242628409.5.0.898202103402.issue4106@psf.upfronthosting.co.za>


Changes by Bobby Impollonia <bobbyi at gmail.com>:


----------
nosy: +bobbyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Mon May 18 08:57:24 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 06:57:24 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242629844.23.0.572912074042.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Here a small, standalone test program of the hires timer code from 
_lsprof4.c.

The results from 10 different builds are included in the comment.

----------
Added file: http://bugs.python.org/file14006/hpTime.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

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: [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 11:25:29 2009
From: report at bugs.python.org (engelbert gruber)
Date: Mon, 18 May 2009 09:25:29 +0000
Subject: [issue5476] datetime: timedelta(minutes = i) silently fails with
	numpy.int32 input
In-Reply-To: <1236786647.39.0.745171492116.issue5476@psf.upfronthosting.co.za>
Message-ID: <1242638729.28.0.179274756055.issue5476@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

testing with 2.6 and numpy 1.3 already ::

   timedelta(seconds = int32(36)) 
   TypeError: unsupported type for timedelta seconds component: 
numpy.int32

But not if I apply a change to numpy to fix issue2263
then ``timedelta(days = int32(36))`` and ``timedelta(minutes = 
int32(36))`` result in wrong timedeltas.

----------
nosy: +grubert
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5476>
_______________________________________

From report at bugs.python.org  Mon May 18 11:41:25 2009
From: report at bugs.python.org (Shish)
Date: Mon, 18 May 2009 09:41:25 +0000
Subject: [issue3949] curses' sigwinch handler isn't visible from python
In-Reply-To: <1222204708.76.0.512730295083.issue3949@psf.upfronthosting.co.za>
Message-ID: <1242639685.44.0.185209083565.issue3949@psf.upfronthosting.co.za>


Shish <shish+python at shishnet.org> added the comment:

in its simplest form, this shows the bug -- signal.getsignal does not 
return the original signal handler (the "tell the app to resize itself" 
one that curses installs), and so, the original signal handler cannot 
be re-activated after being temporarily disabled

~~~~~~~~~~~~~~

import curses
import signal

curses.initscr()
old_winch = signal.getsignal(signal.SIGWINCH)
curses.endwin()
print old_winch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3949>
_______________________________________

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: [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:52 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 May 2009 11:07:52 +0000
Subject: [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 13:14:08 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 May 2009 11:14:08 +0000
Subject: [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <1242645248.24.0.610424425234.issue6053@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is workaround for second issue. If there is tar command for windows
which supports drive letter, I think I should use it instead of
workaround or fix, though.

----------
keywords: +patch
Added file: http://bugs.python.org/file14007/workaround_tar_problem.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6053>
_______________________________________

From report at bugs.python.org  Mon May 18 13:15:04 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 May 2009 11:15:04 +0000
Subject: [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <1242645304.15.0.740665684065.issue6053@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file14008/fix_distutils_ensure_relative.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6053>
_______________________________________

From report at bugs.python.org  Mon May 18 14:51:02 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 May 2009 12:51:02 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1242651062.23.0.881837774389.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've improved the symlink support in jaraco.windows (SVN).  It now
implements the symlink check based on the technique suggested by the
MSDN docs.

I've begun to port this functionality to CPython.  I'm attaching a patch
against /branches/py3k that I believe will expose the a symlink function
on Windows systems.  I don't have an environment set up to compile
Python, so the patch hasn't even been checked for valid syntax.

I would appreciate if someone could review the patch and comment on the
technique.  I'm looking for confirmation that this is a reasonable
approach, or suggestions.

Implementing os.link will probably follow the same technique.

The implementation for ntpath.symlink will be incongruent to the posix
implementation, because it can't use lstat (which doesn't appear to
reflect the symlink flag).  Can ntpath call back into the os module
(where a islink could be defined for Windows systems)?

----------
keywords: +patch
Added file: http://bugs.python.org/file14009/windows symlink draft 1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon May 18 14:51:53 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 May 2009 12:51:53 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1242651113.11.0.0693443604361.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file13948/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon May 18 17:56:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 May 2009 15:56:17 +0000
Subject: [issue6037] MutableSequence.__iadd__ should return self
In-Reply-To: <1242467148.54.0.030236085026.issue6037@psf.upfronthosting.co.za>
Message-ID: <1242662177.83.0.545953603522.issue6037@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r72772 et al.  Thanks for the report

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6037>
_______________________________________

From report at bugs.python.org  Mon May 18 17:58:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 May 2009 15:58:58 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>
Message-ID: <1242662338.98.0.930467939098.issue3023@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe the title problem is solved by PEP 383 in py3k trunk.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

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: [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:29:52 2009
From: report at bugs.python.org (engelbert gruber)
Date: Mon, 18 May 2009 16:29:52 +0000
Subject: [issue2263] struct.pack() + numpy int raises SystemError
In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za>
Message-ID: <1242664192.31.0.148448126242.issue2263@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

issue5476 has a problem with timedelta(microseconds = int32(36))

interestingly 0 to 35 work , if the patch for this issue2263 is applied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2263>
_______________________________________

From report at bugs.python.org  Mon May 18 18:40:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 May 2009 16:40:45 +0000
Subject: [issue6052] for-loop doesn't work with -c
In-Reply-To: <1242642541.14.0.852784948983.issue6052@psf.upfronthosting.co.za>
Message-ID: <1242664845.93.0.615926748279.issue6052@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The error message is correct: your example is invalid python code.  Try
it in a file and you will get the same error message.  Check the
documentation of the '-c' option to learn how to correctly code your
example.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6052>
_______________________________________

From report at bugs.python.org  Mon May 18 18:44:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 May 2009 16:44:45 +0000
Subject: [issue5337] Scanner class in re module undocumented
In-Reply-To: <1235235366.45.0.579114073683.issue5337@psf.upfronthosting.co.za>
Message-ID: <1242665085.52.0.681427086699.issue5337@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is very old code, without a mature API.  Will take a look at
competing recipes to see if this is still the best way of doing this. 
Maybe it should return a generator instead of a list.  Perhaps there
should be some checking for re's that don't combine well.  Also, would
like to see it exercised on a number of common parsing tasks to see how
well it holds up.  Better to do this work than to expose what is there
now and get hit with bug reports, feature requests, deprecations, and
cases where is it almost the right tool for the job.

----------
priority:  -> low
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5337>
_______________________________________

From report at bugs.python.org  Mon May 18 18:52:28 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 18 May 2009 16:52:28 +0000
Subject: [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 18:55:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 May 2009 16:55:36 +0000
Subject: [issue920573] http libraries throw errors internally in BitTorrent
Message-ID: <1242665736.21.0.115290405069.issue920573@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It looks like both pieces of offending code were changed long ago.  No
new bug reports have surfaced since then.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue920573>
_______________________________________

From report at bugs.python.org  Mon May 18 19:01:37 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 18 May 2009 17:01:37 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1242666097.27.0.227786577499.issue5219@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Not issue 1529353.  Edit window stops updating after about 60 
keystrokes when a tooltip window is active.

1. Strings not necessary.  Only occurs when a tooltip is active.  For 
example, if rz is undefined, entering rz( followed by a long key 
sequence won't raise the bug.

2. When the tooltip window closes, the hidden keystrokes appear.  This 
can be triggered by moving the edit window or clicking somewhere. Once 
the tooltip window has closed, things act normally again.

3. Remarkably, one can autorepeat, say, five lines of 'i' with no 
problem.  Then enter another 50 - 60 'i' individually, and the bug 
exhibits.  I thought that typematic processing took place at the 
keyboard driver level, so that Tk would get passed the equivalent of 
single keystrokes.

This bug would be annnoying when entering long parameter tuples, e.g. 
when doing GUI coding.

I'm running Tk 8.5 on WinXP at the moment.   I'm guessing that this is 
a Tk bug.

----------
assignee:  -> kbk
components: +Tkinter
nosy: +kbk
priority: normal -> high
stage:  -> needs patch
status: pending -> open
title: IDLE: slowness, pauses enter long strings -> IDLE/Tkinter: edit win stops updating when tooltip is active
type: performance -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Mon May 18 19:02:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 May 2009 17:02:27 +0000
Subject: [issue966625] Documentation for Descriptors in the main docs
Message-ID: <1242666147.05.0.748085483975.issue966625@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue966625>
_______________________________________

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: [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 20:06:28 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 18 May 2009 18:06:28 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1242669988.55.0.399302650783.issue5219@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

As a workaround, if you need the tooltip, select Edit / Show Calltip 
from the menu or use the hotkey to 'reopen' the tooltip.  That will get 
you another 60 characters.  Otherwise, just hit esc to close the 
tooltip and your keystrokes will appear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Mon May 18 20:34:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 May 2009 18:34:10 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>
Message-ID: <1242671650.14.0.35299907639.issue3023@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

From report at bugs.python.org  Mon May 18 20:46:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 May 2009 18:46:59 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1242672419.69.0.639364476781.issue6056@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Mon May 18 20:50:35 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 18 May 2009 18:50:35 +0000
Subject: [issue1689458] pdb unable to jump to first statement
Message-ID: <1242672635.07.0.00869041008453.issue1689458@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

The attached patch fixes this problem and adds a test. I'll wait a day
for any comments before committing it. Review at
http://codereview.appspot.com/67063.

----------
keywords: +needs review, patch
nosy: +jyasskin
stage: test needed -> patch review
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file14010/jump_to_firstlineno.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1689458>
_______________________________________

From report at bugs.python.org  Mon May 18 20:55:11 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 18 May 2009 18:55:11 +0000
Subject: [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: <1242672911.11.0.641137001672.issue6055@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

I see that the _sqlite .h and .c files, and the sqlite3/dbapi2.py file,
all use "pysqlite" instead of "sqlite3" internally. Should that be
changed too, or is there just no point? My main concern is that people
relatively new to Python who wouldn't be aware of the long history some
modules have and their migration from external packages into the
distribution (often with a name change) will be confused by mentions of
pysqlite in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6055>
_______________________________________

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: [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 report at bugs.python.org  Mon May 18 21:18:21 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 18 May 2009 19:18:21 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1242674301.29.0.479962003706.issue6056@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Pickling the queue and then unpickling it in a new process is something I 
never thought of. That's interesting in and of itself ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Mon May 18 22:09:08 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 20:09:08 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242677348.95.0.873361413824.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Both the hires_lsprof4.tgz and hpTime.c files have been updated with a 
change in the PowerPC asm code.

The previous implementation used a loop: label and that may cause 
duplicate symbols when compiled at optimization levels of -O3 and above 
with older GNU C compilers.

----------
Added file: http://bugs.python.org/file14011/hires_lsprof4.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Mon May 18 22:10:54 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 20:10:54 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242677454.18.0.913486340857.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Another test build and result has been added to the hpTime.c comment.

----------
Added file: http://bugs.python.org/file14012/hpTime.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Mon May 18 22:11:27 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 20:11:27 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242677487.83.0.851288455685.issue2281@psf.upfronthosting.co.za>


Changes by Jean Brouwers <MrJean1 at Gmail.com>:


Removed file: http://bugs.python.org/file14004/hires_lsprof4.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Mon May 18 22:11:33 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 18 May 2009 20:11:33 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1242677493.35.0.421712611595.issue2281@psf.upfronthosting.co.za>


Changes by Jean Brouwers <MrJean1 at Gmail.com>:


Removed file: http://bugs.python.org/file14006/hpTime.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Mon May 18 22:37:24 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 18 May 2009 20:37:24 +0000
Subject: [issue6032] Fix refleaks in test_urllib2_localnet
In-Reply-To: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>
Message-ID: <1242679044.17.0.785572860087.issue6032@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Daniel, did you have any comments on this patch? If not, I'll go ahead
and commit it and close both of these issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6032>
_______________________________________

From report at bugs.python.org  Mon May 18 22:40:42 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 18 May 2009 20:40:42 +0000
Subject: [issue6002] test_urllib2_localnet DigestAuthHandler leaks nonces
In-Reply-To: <1242081235.08.0.896974873294.issue6002@psf.upfronthosting.co.za>
Message-ID: <1242679242.91.0.0577107568945.issue6002@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I've posted a patch in issue 6032 (didn't see this one); I'd be
interested in any comments on the approach taken there.

----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6002>
_______________________________________

From report at bugs.python.org  Mon May 18 23:24:50 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 18 May 2009 21:24:50 +0000
Subject: [issue6032] Fix refleaks in test_urllib2_localnet
In-Reply-To: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>
Message-ID: <1242681890.77.0.423343442894.issue6032@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

LGTM :)

This part changes the output in verbose mode, not sure it's necessary
(but not a real problem either):

-    test_support.run_unittest(ProxyAuthTests)
-    test_support.run_unittest(TestUrlopen)
+    test_support.run_unittest(ProxyAuthTests, TestUrlopen)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6032>
_______________________________________

From report at bugs.python.org  Mon May 18 23:39:35 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 18 May 2009 21:39:35 +0000
Subject: [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1242682775.86.0.827560681582.issue3541@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I can confirm it in trunk and release26-maint on Ubuntu 8.04.

For trunk:
bsddb.__version__ : '4.7.3'
libdb4.6-dev: 4.6.21-6ubuntu1
_bsddb.version(): (4, 6, 21)
bsddb._bsddb.cvsid: '$Id: _bsddb.c 66568 2008-09-23 18:54:08Z jesus.cea $'

----------
resolution: out of date -> 
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________

From report at bugs.python.org  Mon May 18 23:48:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 May 2009 21:48:35 +0000
Subject: [issue5964] WeakSet cmp methods
In-Reply-To: <1241744842.61.0.823146195482.issue5964@psf.upfronthosting.co.za>
Message-ID: <1242683315.68.0.24614201416.issue5964@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5964>
_______________________________________

From report at bugs.python.org  Tue May 19 00:34:18 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 18 May 2009 22:34:18 +0000
Subject: [issue6002] test_urllib2_localnet DigestAuthHandler leaks nonces
In-Reply-To: <1242081235.08.0.896974873294.issue6002@psf.upfronthosting.co.za>
Message-ID: <1242686058.44.0.218406938504.issue6002@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Daniel Diniz reviewed in the other issue.

Fixed in r72777 (trunk), r72778 (py3k).

----------
assignee:  -> collinwinter
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6002>
_______________________________________

From report at bugs.python.org  Tue May 19 00:34:38 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 18 May 2009 22:34:38 +0000
Subject: [issue6032] Fix refleaks in test_urllib2_localnet
In-Reply-To: <1242434834.43.0.129192851177.issue6032@psf.upfronthosting.co.za>
Message-ID: <1242686078.27.0.642358316909.issue6032@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Applied as r72777 (trunk), r72778 (py3k).

----------
assignee:  -> collinwinter
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6032>
_______________________________________

From report at bugs.python.org  Tue May 19 01:17:47 2009
From: report at bugs.python.org (Ryan Stutsman)
Date: Mon, 18 May 2009 23:17:47 +0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1242688667.42.0.0637009018055.issue1983@psf.upfronthosting.co.za>


Ryan Stutsman <stutsman at stanford.edu> added the comment:

No, I don't think this is actually fixed in any version of Python at the
moment.  The title may be a bit misleading, because all the versions now
store the result of fork in a pid_t and return it as a PyLong.  However,
posix_waitpid is still pulling pid's as a PyInt.  Changing this to
PyLong would probably work for our purposes, but I guess the hangup was
that in reality pid_t is supposed to be an opaque datatype and
implementing it in CPython is non-trivial and has little benefit.

Perhaps we close this as won't fix or I can create a patch to at least
give a hack for 64-bit pid's but still treated as a long.

----------
nosy: +rstutsman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
_______________________________________

From report at bugs.python.org  Tue May 19 02:27:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 May 2009 00:27:45 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1242692865.59.0.414372241641.issue6058@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

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: [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 05:15:28 2009
From: report at bugs.python.org (Aren Olson)
Date: Tue, 19 May 2009 03:15:28 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1242702928.59.0.345628624525.issue1722344@psf.upfronthosting.co.za>


Changes by Aren Olson <reacocard at gmail.com>:


----------
nosy: +reacocard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue May 19 05:29:37 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 19 May 2009 03:29:37 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1242703777.42.0.373571829981.issue5219@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Occurs with and w/o the subprocess, but sooner (fewer char) with the 
subprocess.

If the MultiCall wrapper on the EditorWindow Text widget is disabled, 
the bug disappears.

----------
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Tue May 19 06:23:06 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 19 May 2009 04:23:06 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1242706986.57.0.0156377667584.issue5219@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Bug exhibits on Linux with Tk 8.4, but requires a couple hundred 
characters to show up.  Also goes away if MultiCall is disabled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Tue May 19 07:20:27 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Tue, 19 May 2009 05:20:27 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1242710426.4.0.944213497098.issue6056@psf.upfronthosting.co.za>


Ryan Leslie <rylesny at gmail.com> added the comment:

Yeah, storing pickled queues in the file system makes for some easy IPC
:) It wasn't a very original idea, I took the pickling comments in the
documentation at face value:
http://docs.python.org/library/multiprocessing.html#proxy-objects

So, from what I can tell this issue is related to the mixing of standard
python socket I/O with multiprocessing socket I/O, with state not being
carried from the former to the latter.

In multiprocessing/connection.py, SocketClient() creates a familiar
python socket object which, when a default timeout has been set in the
module, will be made non-blocking. In addition, the timeout is
remembered in the socket object, and when calling socket.recv(), the
function internal_select() will use this to perform the expected poll()
or select().

However, after a connection is established, SocketClient() will not use
python's socket implementation any further, and instead pass its
low-level socket descriptor to a multiprocessing Connection object. This
object has its own specialized socket I/O implementation, which is not
at all aware of the timeout previously associated with the socket. As a
result no select/poll occurs and, due to the socket's non-blocking
status, recv() may return EAGAIN immediately. I suspect this is what's
happening.

There might be a number of ways to make SocketClient() more timeout
friendly, but possibility could be to simply check if the python socket
has a timeout associated, and if so, use connection.poll() in addition
to connection.recv(). There may be other places in the code where
similar changes would occur.

You obviously have more experience with this code base so I'll be
curious to see the outcome.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Tue May 19 07:43:41 2009
From: report at bugs.python.org (soundmurderer)
Date: Tue, 19 May 2009 05:43:41 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1242711821.07.0.540936295589.issue858809@psf.upfronthosting.co.za>


soundmurderer <soundmurderer at gmail.com> added the comment:

OK, I am now convinced that even with this patch, the Python build
process still won't work correctly because --libdir (post-patch) will
not correctly set the default PYTHONHOME.  Moreover, the very way that
PYTHONHOME gets used needs to change.  PYTHONHOME specifies "prefix"
and/or "exec_prefix", but the problem is that to find the lib dir,
Python tacks "lib/pythonX.X" onto the ends of these paths!  More info here:

http://docs.python.org/using/unix.html#python-related-paths-and-files
http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME

So, even with this patch, I still can't install, for example, to:
/home/soundmurderer/lib/x86_64/python2.6

I am forced to install to a location that ends with "lib/python2.6", e.g.:

/home/soundmurderer/x86_64/lib/python2.6

or else hack some stuff together with symlinks to make PYTHONHOME go to
the right place.

This seems to be a problem more fundamental than just incomplete
"./configure" in the build process and I think it warrants another
ticket, which I'm about to open.

Now, in regards to --libdir, even though the patch makes the
installation put the files in the expected location, Python will
probably not find it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

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: [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 07:53:37 2009
From: report at bugs.python.org (soundmurderer)
Date: Tue, 19 May 2009 05:53:37 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1242712417.05.0.841161936262.issue858809@psf.upfronthosting.co.za>


soundmurderer <soundmurderer at gmail.com> added the comment:

OK done, opened a feature request for this pet peeve of mine. ;-)  Maybe
someday I'll complain about something substantial...

See: http://bugs.python.org/issue6060

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Tue May 19 08:30:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 May 2009 06:30:45 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1242714645.82.0.743154440057.issue1309352@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@AP: ran patched test on Freebsd (6.2) as requested.  Result is:

test_fcntl_64_bit (test.test_fcntl.TestFcntl) ... skipped 'F_NOTIFY or
DN_MULTISHOT unavailable'

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Tue May 19 08:43:04 2009
From: report at bugs.python.org (Thomas Reiter)
Date: Tue, 19 May 2009 06:43:04 +0000
Subject: [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 08:57:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 06:57:02 +0000
Subject: [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: <1242716222.38.0.981417484843.issue6061@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

time.clock() is a simple wrapper around the C stdlib clock() function.
As the clock() man page says:

? Note that the time can wrap around.  On a 32-bit system where
CLOCKS_PER_SEC equals 1000000 this function will return the same value
approximately every 72 minutes. ?

Is it a 32-bit or 64-bit Python build? (you might have a 32-bit build on
a 64-bit system)
If it is a 64-bit build, what are sizeof(clock_t) and CLOCKS_PER_SEC on
a your system? You can compile the following small C program to get the
answer.

#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
    printf("sizeof(clock_t)=%d, CLOCKS_PER_SEC=%d\n",
           sizeof(clock_t), CLOCKS_PER_SEC);
    return 0;
}

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6061>
_______________________________________

From report at bugs.python.org  Tue May 19 09:01:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:01:13 +0000
Subject: [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: <1242716473.4.0.210197173456.issue6061@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is very likely you have a 32-bit Python build because:

>>> 2**32/1000000.
4294.9672959999998

and 4294 is exactly the number of seconds by which your clock() value
wraps around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6061>
_______________________________________

From report at bugs.python.org  Tue May 19 09:36:46 2009
From: report at bugs.python.org (sol)
Date: Tue, 19 May 2009 07:36:46 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1241514358.94.0.308720465949.issue3585@psf.upfronthosting.co.za>
Message-ID: <20090519073642.GA22718@john>


sol <simon.hengel at wiktory.org> added the comment:

I totally agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Tue May 19 09:36:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:36:50 +0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1242718610.69.0.935185611378.issue1983@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following patch should do the trick.

----------
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file14016/issue1983.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
_______________________________________

From report at bugs.python.org  Tue May 19 09:37:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:37:10 +0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1242718630.98.0.18507866706.issue1983@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: fixed -> 
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
_______________________________________

From report at bugs.python.org  Tue May 19 09:38:27 2009
From: report at bugs.python.org (Thomas Reiter)
Date: Tue, 19 May 2009 07:38:27 +0000
Subject: [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: <1242718707.33.0.179194619128.issue6061@psf.upfronthosting.co.za>


Thomas Reiter <thomasr at nikhef.nl> added the comment:

That version of Python is linked against 32-bit libc. Point of overflow
corresponds to
2^31 us.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6061>
_______________________________________

From report at bugs.python.org  Tue May 19 09:52:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:52:12 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1242719532.78.0.0748999802946.issue3585@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks good here.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Tue May 19 09:52:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:52:48 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1242719568.01.0.733963696163.issue6058@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Tue May 19 09:54:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:54:22 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1242719662.76.0.695360521508.issue1602@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Tue May 19 09:56:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 07:56:41 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1242719801.01.0.222301729876.issue1722344@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue May 19 10:14:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 08:14:38 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1242720878.38.0.05287065942.issue6042@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't say anything about the simplification since I never use tracing,
but +1 at least on the doc cleanup.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Tue May 19 11:46:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 May 2009 09:46:14 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1242726374.68.0.248484835786.issue1602@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

an immediate thing to do is to declare cp65001 as an encoding:

Index: Lib/encodings/aliases.py
===================================================================
--- Lib/encodings/aliases.py    (revision 72757)
+++ Lib/encodings/aliases.py    (working copy)
@@ -511,6 +511,7 @@
     'utf8'               : 'utf_8',
     'utf8_ucs2'          : 'utf_8',
     'utf8_ucs4'          : 'utf_8',
+    'cp65001'            : 'utf_8',

     ## uu_codec codec
     #'uu'                 : 'uu_codec',

This is not enough unfortunately, because the win32 API function
WriteFile() returns the number of characters written, not the number of
(utf8) bytes:

>>> print("\u0124\u0102" + 'abc')
??abc
c
[44420 refs]
>>>

Additionally, there is a bug in the ReadFile, which returns an empty
string (and no error) when a non-ascii character is entered, which is
the behavior of an EOF condition...

Maybe the solution is to use the win32 console API directly...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Tue May 19 15:10:38 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 May 2009 13:10:38 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1242738638.57.0.439999838454.issue6056@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Well; I'm pretty tapped out right now - I think your idea of checking to 
see if a timeout has been set elsewhere makes sense. If you have the time 
to put together a patch (with a unit test or three :)) I can review it. 
Might take me a bit of time to get to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Tue May 19 17:37:07 2009
From: report at bugs.python.org (Tristam MacDonald)
Date: Tue, 19 May 2009 15:37:07 +0000
Subject: [issue1761028] pickle - cannot unpickle circular deps with custom
	__hash__
Message-ID: <1242747427.08.0.235525277859.issue1761028@psf.upfronthosting.co.za>


Changes by Tristam MacDonald <swiftcoder at gmail.com>:


----------
nosy: +swiftcoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1761028>
_______________________________________

From report at bugs.python.org  Tue May 19 17:39:38 2009
From: report at bugs.python.org (Tristam MacDonald)
Date: Tue, 19 May 2009 15:39:38 +0000
Subject: [issue1761028] pickle - cannot unpickle circular deps with custom
	__hash__
Message-ID: <1242747578.61.0.239095515071.issue1761028@psf.upfronthosting.co.za>


Tristam MacDonald <swiftcoder at gmail.com> added the comment:

Is there any sign of a patch or workaround for this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1761028>
_______________________________________

From report at bugs.python.org  Tue May 19 18:24:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 May 2009 16:24:27 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1242750267.06.0.131792045179.issue1309352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @AP: ran patched test on Freebsd (6.2) as requested.

Thanks! For the record, did the rest of test_fcntl pass?
Is it a 32-bit or a 64-bit build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Tue May 19 19:11:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 May 2009 17:11:56 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
In-Reply-To: <1242750267.06.0.131792045179.issue1309352@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0905191310440.3802@kimball.webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Tue, 19 May 2009 at 16:24, Antoine Pitrou wrote:
> Thanks! For the record, did the rest of test_fcntl pass?
> Is it a 32-bit or a 64-bit build?

Yes and 32 bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Tue May 19 20:14:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 May 2009 18:14:59 +0000
Subject: [issue6060] PYTHONHOME should be more flexible (and controllable by
	--libdir)
In-Reply-To: <1242712344.32.0.862299052402.issue6060@psf.upfronthosting.co.za>
Message-ID: <1242756899.43.0.967254159343.issue6060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

PYTHONHOME is defined as 'prefix:exec-prefix'.  Given that definition
the library must be resolved relatively by appending 'lib/pythonX.Y'. 
Given the long standing nature of this interface, I doubt the meaning
can be changed.

It might be possible to _extend_ the definition of PYTHONHOME to have
additional elements, one of which would be libdir.  It seems to me that
this would be backward compatible.  This possibility, and/or other
solutions, would be more appropriately discussed on python-ideas.  And
then of course someone would have to develop a patch to implement
whatever scheme wins consensus (assuming the consensus is that this is a
problem worth solving).

----------
nosy: +r.david.murray
priority:  -> normal
versions: +Python 2.7, Python 3.2 -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 20:18:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 May 2009 18:18:15 +0000
Subject: [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: <1242757095.49.0.461085874548.issue6022@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's not just on the buildbots, it passes fine on my Gentoo box.  So the
question really is, what's different about your box that makes it fail?
 Can you figure out what bit of code is not finding that library?

How do you run the tests?  Maybe that makes a difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

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: [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:11:25 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:11:25 +0000
Subject: [issue4554] Missing  make altframeworkinstall for Mac OS X
In-Reply-To: <1228525462.29.0.299893265835.issue4554@psf.upfronthosting.co.za>
Message-ID: <1242760285.94.0.408213101385.issue4554@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing as won't fix because you can use "make altinstall".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4554>
_______________________________________

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: [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 21:14:08 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:14:08 +0000
Subject: [issue5269] OS X Installer: add options to specify universal build
	type and deployment target
In-Reply-To: <1234687874.34.0.561795974463.issue5269@psf.upfronthosting.co.za>
Message-ID: <1242760448.97.0.854855812304.issue5269@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing this issue because it was fixed a while back. The bsddb test 
failure I rever to in my previous message turned out to be a non-issue: 
these tests just take a very long time to finish.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5269>
_______________________________________

From report at bugs.python.org  Tue May 19 21:17:13 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:17:13 +0000
Subject: [issue5272] OS X installer: fix makefile target changed for 3.x
In-Reply-To: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
Message-ID: <1242760633.27.0.97713497053.issue5272@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

"make fullinstall" is wrong, this will install a "python" executable as 
well as the proper "python3" and "python3.1" executables.

I'll do a build of the 3.1 installer ASAP and fix any issues with that.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________

From report at bugs.python.org  Tue May 19 21:25:47 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:25:47 +0000
Subject: [issue3791] bsddb not completely removed
In-Reply-To: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>
Message-ID: <1242761147.81.0.696895106817.issue3791@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The mac issue mentioned by "karlcow" is not relevant for this discussion 
and refers to the system install of Python. 

The python.org maintainers cannot influence the behaviour of that 
installation, especially not w.r.t. the installation of optional extras 
like bsddb.

BTW. Can this issue be closed? 

BTW2. Switching "components" from Macintosh to "Installation" because 
this is not related to the macos port.

----------
components: +Installation -Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3791>
_______________________________________

From report at bugs.python.org  Tue May 19 21:30:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:30:58 +0000
Subject: [issue5769] OS X Installer: new make of documentation installs at
	wrong location
In-Reply-To: <1239864540.13.0.520124833397.issue5769@psf.upfronthosting.co.za>
Message-ID: <1242761458.88.0.931822767946.issue5769@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've recently fixed this for 3.1, and fixed this for 2.x a while back.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5769>
_______________________________________

From report at bugs.python.org  Tue May 19 21:37:03 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:37:03 +0000
Subject: [issue892707] debuggable/profileable Python framework
Message-ID: <1242761823.87.0.690722117437.issue892707@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This might be useful for profiling. Debugging information is already 
present in the default build of the framework.

A seperate binary for --with-pydebug won't be possible as AFAIK --with-
pydebug changes the ABI and hence having both in the same framework will 
cause problems for extensions.

I'm not planning to work on this, but would be willing to review a patch.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue892707>
_______________________________________

From report at bugs.python.org  Tue May 19 21:39:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 May 2009 19:39:20 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1242761960.89.0.547829351425.issue6064@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Tue May 19 21:39:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 May 2009 19:39:32 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1242761972.09.0.454535613692.issue6064@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Tue May 19 21:52:01 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 19:52:01 +0000
Subject: [issue4834] Trouble configuring with icc on Mac OS X 10.5
In-Reply-To: <18784.64250.252843.484595@montanaro.dyndns.org>
Message-ID: <1242762721.49.0.42366916623.issue4834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Skip could you please answer the questions in msg83149?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4834>
_______________________________________

From report at bugs.python.org  Tue May 19 22:14:26 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 20:14:26 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1242764066.63.0.498179285552.issue6003@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch implements my proposal, including documentation and 
tests. I'm not 100% happy about the tests, they may be a bit too minimal.

----------
keywords: +patch
Added file: http://bugs.python.org/file14018/zipfile_writestr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6003>
_______________________________________

From report at bugs.python.org  Tue May 19 22:15:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 May 2009 20:15:30 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1242764130.79.0.178790029731.issue6003@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Argh... The patch includes an update to configure.in, please ignore that 
bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6003>
_______________________________________

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: [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>

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()\
-------------- 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 00:03:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 May 2009 22:03:24 +0000
Subject: [issue5942] Ambiguity in dbm.open flag documentation
In-Reply-To: <1241531904.72.0.756438187813.issue5942@psf.upfronthosting.co.za>
Message-ID: <1242770604.24.0.967646053153.issue5942@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It was my mistake -- anydbm is called dbm in py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5942>
_______________________________________

From report at bugs.python.org  Wed May 20 00:21:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 May 2009 22:21:13 +0000
Subject: [issue6063] pydoc_data package is not installed
In-Reply-To: <1242760110.37.0.882405849685.issue6063@psf.upfronthosting.co.za>
Message-ID: <1242771673.71.0.289301532426.issue6063@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for fixing!  There's no need to backport; the pydoc_data package
is new in 2.7/3.1.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6063>
_______________________________________

From report at bugs.python.org  Wed May 20 01:25:10 2009
From: report at bugs.python.org (George Sakkis)
Date: Tue, 19 May 2009 23:25:10 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1242775510.59.0.0943215506178.issue5982@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

I don't remember the exact use case but it had to do with making a
decorator robust enough to work for different kinds of callables (and a
few common non-callables such as classmethod/staticmethod). It's not a
show stopper by any means but I thought it would be easy (if not
trivial) to implement, and regardless of actual use cases I don't see a
reason to keep the function "hidden".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

From report at bugs.python.org  Wed May 20 01:38:14 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 19 May 2009 23:38:14 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1242776294.1.0.174157290464.issue858809@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
assignee:  -> tarek
components: +Distutils
nosy: +tarek
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1 -Python 2.5, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Wed May 20 03:27:35 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 May 2009 01:27:35 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1242782855.9.0.261636279891.issue5982@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I am all for exposing the __func__ directly but don't immediately see
how to do it.

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

From report at bugs.python.org  Wed May 20 03:28:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 May 2009 01:28:12 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1242782892.77.0.931836783912.issue2690@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Wed May 20 03:31:07 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 May 2009 01:31:07 +0000
Subject: [issue5337] Scanner class in re module undocumented
In-Reply-To: <1235235366.45.0.579114073683.issue5337@psf.upfronthosting.co.za>
Message-ID: <1242783067.12.0.321039831191.issue5337@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Looking back at the original thread, good reasons were expresses for not
documenting this code but just leaving it in as an example.

----------
dependencies:  -Regexp 2.7 (modifications to current re 2.2.2)
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5337>
_______________________________________

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: [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 06:05:46 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 20 May 2009 04:05:46 +0000
Subject: [issue6066] POP_MARK was not in pickle protocol 0
In-Reply-To: <1242783073.43.0.508281070334.issue6066@psf.upfronthosting.co.za>
Message-ID: <1242792346.73.0.101525897997.issue6066@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

SHORT_BINBYTES needs to be corrected as well; pickletools lists it as
part of protocol 0 instead of protocol 3.

I doubt backporting this patch to 2.6 will cause any trouble. So, you
can go forward with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6066>
_______________________________________

From report at bugs.python.org  Wed May 20 09:30:47 2009
From: report at bugs.python.org (Tim Golden)
Date: Wed, 20 May 2009 07:30:47 +0000
Subject: [issue6065] bdist_msi.py failed assert when including extension
	modules
In-Reply-To: <4A1329EC.3020307@timgolden.me.uk>
Message-ID: <1242804647.28.0.836516506113.issue6065@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
assignee:  -> tarek
components: +Distutils
nosy: +tarek
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6065>
_______________________________________

From report at bugs.python.org  Wed May 20 10:52:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 May 2009 08:52:01 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1242809521.34.0.467702903069.issue4174@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I am with Raymond here: I don't think the performance improvement would
be worth a significant complification of the code - unless the
improvement is /very/ large.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

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: [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:29:21 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 May 2009 09:29:21 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1242811761.21.0.0255767574854.issue5982@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is there a difficulty I did not see? Here is a patch.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14021/staticmethod_func.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

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: [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: [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:32:54 2009
From: report at bugs.python.org (higstar)
Date: Wed, 20 May 2009 10:32:54 +0000
Subject: [issue6068] c_ulonglong structure members appear read-only
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1242815574.52.0.134982188905.issue6068@psf.upfronthosting.co.za>


Changes by higstar <adrian at higstar.com>:


----------
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

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: [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 13:27:56 2009
From: report at bugs.python.org (James Broadhead)
Date: Wed, 20 May 2009 11:27:56 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242818876.24.0.903820379168.issue1424152@psf.upfronthosting.co.za>


James Broadhead <jamesbroadhead at gmail.com> added the comment:

Has there been any progress on this since January? 


It is causing/affecting:
http://www.selenic.com/mercurial/bts/issue967

----------
nosy: +jamesbroadhead

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed May 20 14:20:55 2009
From: report at bugs.python.org (Hans L)
Date: Wed, 20 May 2009 12:20:55 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242822055.92.0.625206621536.issue1424152@psf.upfronthosting.co.za>


Hans L <hans at velum.net> added the comment:

These patches (well, the 2.6 patch) works for me.  If there's something
I can do to help get this accepted/applied, I'd be happy to do it.
Obviously, I had no part in these patches, but I can take a stab at
updating documentation or something if that is all that is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed May 20 15:20:10 2009
From: report at bugs.python.org (Loris Bennett)
Date: Wed, 20 May 2009 13:20:10 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1242825610.65.0.720453757316.issue941346@psf.upfronthosting.co.za>


Loris Bennett <loris.bennett at fu-berlin.de> added the comment:

Shouldn't line 170 be

   CCOPT="$CCOPT -Wl,-bM:SRE -Wl,-T512 -Wl,-H512 -Wl,-brtl
-Wl,-bnortllib -lm -o $objfile"

instead of

   CCOPT="$CCOPT -Wl,-bM:SRE -Wl,-T512 -Wl,-H512 -brtl -bnortllib -lm -o
$objfile"

Otherwise the -brtl and -bnortllib flags are interpreted as compiler
flags and errors like the following will occur:

   gcc: unrecognized option '-brtl'

----------
nosy: +loris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed May 20 15:33:02 2009
From: report at bugs.python.org (Loris Bennett)
Date: Wed, 20 May 2009 13:33:02 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1242826382.39.0.402465833996.issue941346@psf.upfronthosting.co.za>


Loris Bennett <loris.bennett at fu-berlin.de> added the comment:

Addition to last message:

More importantly, without "-Wl", the flags are not passed to the linker
and the tcl/tk libs will not be found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed May 20 16:02:48 2009
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 20 May 2009 14:02:48 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242828168.24.0.954681330005.issue1424152@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Hans, please take a look to my comment 79573 in this same bug. If you
could do that, it'd be amazing...

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed May 20 17:03:33 2009
From: report at bugs.python.org (Hans Lellelid)
Date: Wed, 20 May 2009 15:03:33 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242831813.24.0.187916932735.issue1424152@psf.upfronthosting.co.za>


Hans Lellelid <hans at velum.net> added the comment:

Sure -- I will tackle that this week; I hope I can come up with
something satisfactory.  As I have not provided doc patches before for
Python I may need to spin up a bit on that (and of course on the exact
meaning of the set_tunnel method in this context) -- but I'm happy to help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed May 20 17:04:02 2009
From: report at bugs.python.org (Senthil)
Date: Wed, 20 May 2009 15:04:02 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
In-Reply-To: <1242822055.92.0.625206621536.issue1424152@psf.upfronthosting.co.za>
Message-ID: <20090520150352.GB16205@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

Sorry for the delay. I know that patches work and I had tested them as
well. I shall push those patches to trunk/p3k within this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed May 20 17:06:59 2009
From: report at bugs.python.org (Senthil)
Date: Wed, 20 May 2009 15:06:59 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <20090520150648.GC16205@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

> Facundo Batista <facundo at taniquetil.com.ar> added the comment:
> 
> Hans, please take a look to my comment 79573 in this same bug. If you
> could do that, it'd be amazing...

Oops, had missed that one.. Shall update the patch, Facundo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed May 20 17:10:49 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 20 May 2009 15:10:49 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1242832249.83.0.472783718711.issue1424152@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

reassigning to the volunteer to get this in :)

----------
assignee: facundobatista -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

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: [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:26:51 2009
From: report at bugs.python.org (ivank)
Date: Wed, 20 May 2009 17:26:51 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1242840411.76.0.994234492512.issue6071@psf.upfronthosting.co.za>


Changes by ivank <ivan at ludios.org>:


----------
nosy: +ivank

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Wed May 20 19:38:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 May 2009 17:38:30 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1242841110.81.0.712182281842.issue6064@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed May 20 19:45:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 May 2009 17:45:18 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1242841518.93.0.0125179307807.issue6071@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's probably because hashlib switched to using the new buffer API,
and array.array() only supports the old one in 2.x.

Perhaps hashlib should have some fallback code for such legacy types...

----------
nosy: +pitrou
priority:  -> high
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Wed May 20 19:48:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 May 2009 17:48:15 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1242841695.53.0.19198549443.issue5982@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

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: [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 19:58:36 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 20 May 2009 17:58:36 +0000
Subject: [issue1689458] pdb unable to jump to first statement
Message-ID: <1242842316.9.0.758872601633.issue1689458@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Fixed in r72796. Will forward-port to py3k shortly.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1689458>
_______________________________________

From report at bugs.python.org  Wed May 20 20:02:50 2009
From: report at bugs.python.org (ivank)
Date: Wed, 20 May 2009 18:02:50 +0000
Subject: [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: <1242842570.59.0.974779240711.issue6072@psf.upfronthosting.co.za>


Changes by ivank <ivan at ludios.org>:


----------
nosy: +ivank

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6072>
_______________________________________

From report at bugs.python.org  Wed May 20 20:08:21 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 20 May 2009 18:08:21 +0000
Subject: [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: <1242842901.81.0.223809534761.issue6072@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Here's a patch which renames `_result? to `_resultForDoCleanups?. 
Another possibility would be for `doCleanups? to take the result object
as an argument.  This would make it harder for applications to call
directly, though (I've never wanted to run cleanups early, though).

----------
keywords: +patch
Added file: http://bugs.python.org/file14022/rename-results.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6072>
_______________________________________

From report at bugs.python.org  Wed May 20 20:15:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 May 2009 18:15:40 +0000
Subject: [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: <1242843340.13.0.26925107858.issue6072@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6072>
_______________________________________

From report at bugs.python.org  Wed May 20 20:23:10 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 20 May 2009 18:23:10 +0000
Subject: [issue5767] xmlrpclib loads invalid documents
In-Reply-To: <1239841199.24.0.504542013197.issue5767@psf.upfronthosting.co.za>
Message-ID: <1242843790.91.0.620986174573.issue5767@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Here's a patch which removes sgmlop support from xmlrpclib.

----------
keywords: +patch
Added file: http://bugs.python.org/file14023/xmlrpclib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5767>
_______________________________________

From report at bugs.python.org  Wed May 20 20:31:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 May 2009 18:31:46 +0000
Subject: [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: <1242844306.37.0.0677682122909.issue6055@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

pysqlite is an alias of sqlite3; it's developed outside of the core
under that name.  I agree that this can be confusing, and I've now
removed almost all mentions (and qualified the remaining one) in r72801.

I will not touch occurrences in source code; this will make syncing with
pysqlite unnecessarily hard.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6055>
_______________________________________

From report at bugs.python.org  Wed May 20 20:32:54 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 May 2009 18:32:54 +0000
Subject: [issue6057] sqlite3 error classes should be documented
In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za>
Message-ID: <1242844374.79.0.59002683082.issue6057@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> ghaering
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6057>
_______________________________________

From report at bugs.python.org  Wed May 20 20:35:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 May 2009 18:35:42 +0000
Subject: [issue6051] smtplib docs should link to email module examples
In-Reply-To: <1242638032.14.0.154359322708.issue6051@psf.upfronthosting.co.za>
Message-ID: <1242844542.02.0.597049702788.issue6051@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added a note and a reference in r72802.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6051>
_______________________________________

From report at bugs.python.org  Wed May 20 20:41:56 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 20 May 2009 18:41:56 +0000
Subject: [issue5485] pyexpat has no unit tests for UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1242844916.14.0.595093324965.issue5485@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Here's a new patch which adds SetParamEntityParsing to the pyexpat
library docs and adds another test for external entity reference
handling.  This is probably all I'll do on this ticket.

----------
Added file: http://bugs.python.org/file14024/pyexpat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5485>
_______________________________________

From report at bugs.python.org  Wed May 20 20:43:23 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 May 2009 18:43:23 +0000
Subject: [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: <1242845003.45.0.0743106745769.issue6072@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Patch is fine. I'll apply shortly. There was a specific use case for
being able to call doCleanups directly which was why the results object
needed to be stored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6072>
_______________________________________

From report at bugs.python.org  Wed May 20 20:44:39 2009
From: report at bugs.python.org (David Andrzejewski)
Date: Wed, 20 May 2009 18:44:39 +0000
Subject: [issue1711603] logging
Message-ID: <1242845079.76.0.945612714982.issue1711603@psf.upfronthosting.co.za>


Changes by David Andrzejewski <david.andrzejewski at gmail.com>:


----------
title: syslog syscall support for SysLogLogger -> logging
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Wed May 20 20:45:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 May 2009 18:45:11 +0000
Subject: [issue5829] float('1e500') -> inf, complex('1e500') -> ValueError
In-Reply-To: <1240575981.53.0.816378591256.issue5829@psf.upfronthosting.co.za>
Message-ID: <1242845111.86.0.876140204361.issue5829@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Eric.  Committed in r72803;  backported to trunk in r72805.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5829>
_______________________________________

From report at bugs.python.org  Wed May 20 20:45:33 2009
From: report at bugs.python.org (David Andrzejewski)
Date: Wed, 20 May 2009 18:45:33 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger -> logging
Message-ID: <1242845133.53.0.782294767336.issue1711603@psf.upfronthosting.co.za>


Changes by David Andrzejewski <david.andrzejewski at gmail.com>:


----------
title: logging -> syslog syscall support for SysLogLogger -> logging
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Wed May 20 20:45:47 2009
From: report at bugs.python.org (David Andrzejewski)
Date: Wed, 20 May 2009 18:45:47 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger
Message-ID: <1242845147.39.0.551207185367.issue1711603@psf.upfronthosting.co.za>


Changes by David Andrzejewski <david.andrzejewski at gmail.com>:


----------
title: syslog syscall support for SysLogLogger -> logging -> syslog syscall support for SysLogLogger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Wed May 20 21:05:44 2009
From: report at bugs.python.org (Collin Winter)
Date: Wed, 20 May 2009 19:05:44 +0000
Subject: [issue6066] POP_MARK was not in pickle protocol 0
In-Reply-To: <1242783073.43.0.508281070334.issue6066@psf.upfronthosting.co.za>
Message-ID: <1242846344.44.0.347265143183.issue6066@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Applied in r72792 (trunk), r72793 (py3k), r72808 (release26-maint).

----------
assignee:  -> collinwinter
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6066>
_______________________________________

From report at bugs.python.org  Wed May 20 21:10:45 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 20 May 2009 19:10:45 +0000
Subject: [issue1689458] pdb unable to jump to first statement
Message-ID: <1242846645.53.0.45487292196.issue1689458@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Merged to py3k in r72809.

----------
status: open -> closed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1689458>
_______________________________________

From report at bugs.python.org  Wed May 20 21:51:15 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 May 2009 19:51:15 +0000
Subject: [issue4547] Long jumps with frame_setlineno
In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za>
Message-ID: <1242849075.29.0.0938179932419.issue4547@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think you can apply this.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4547>
_______________________________________

From report at bugs.python.org  Wed May 20 22:10:37 2009
From: report at bugs.python.org (Clifford W Johnson)
Date: Wed, 20 May 2009 20:10:37 +0000
Subject: [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: <1242850237.88.0.109911155966.issue6029@psf.upfronthosting.co.za>


Clifford W Johnson <Clifford at IEEE.org> added the comment:

The following script (based on an extract of test_callbacks.py)
demonstrates the problem.  When run on a Sparc-based Solaris 10
platform, the output shows correct operation only when the c_longdouble
arguments appear first in the function call -- the use of other types
would seem to throw off argument alignment.

Could this be an issue with libffi?

#!/bin/env python

import sys
from ctypes import *


class Callback:
    functype = CFUNCTYPE

    def callback(self, *args):
        self.got_args = args
        return args[-1]

    def check_type(self, typ, arg):
        print "typ=%s" % (typ,)

        print "Trying (typ) ..."
        PROTO = self.functype.im_func(typ, typ)
        result = PROTO(self.callback)(arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "Trying (c_byte, typ) ..."
        PROTO = self.functype.im_func(typ, c_byte, typ)
        result = PROTO(self.callback)(-3, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "Trying (typ, c_byte) ..."
        PROTO = self.functype.im_func(typ, typ, c_byte)
        result = PROTO(self.callback)(arg, -3)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "Trying (c_byte, typ, typ) ..."
        PROTO = self.functype.im_func(typ, c_byte, typ, typ)
        result = PROTO(self.callback)(-3, arg, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "Trying (typ, typ) ..."
        PROTO = self.functype.im_func(typ, typ, typ)
        result = PROTO(self.callback)(arg, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "Trying (c_double, typ) ..."
        PROTO = self.functype.im_func(typ, c_double, typ)
        result = PROTO(self.callback)(arg, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "trying (c_int, typ) ..."
        PROTO = self.functype.im_func(typ, c_int, typ)
        result = PROTO(self.callback)(-3, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "trying (c_long, typ) ..."
        PROTO = self.functype.im_func(typ, c_long, typ)
        result = PROTO(self.callback)(-3, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

        print "trying (c_longlong, typ) ..."
        PROTO = self.functype.im_func(typ, c_longlong, typ)
        result = PROTO(self.callback)(-3, arg)
        print "    %s result=%s; got_args=%r" % ("*FAILED*" if result !=
3.14 else "WORKED", result, self.got_args)

callback = Callback()
callback.check_type(c_longdouble, 3.14)
# callback.check_type(c_longdouble, -3.14)


> ./python ~/tryLongDouble.py
typ=<class 'ctypes.c_longdouble'>
Trying (typ) ...
    WORKED result=3.14; got_args=(3.1400000000000001,)
Trying (c_byte, typ) ...
    *FAILED* result=0.0; got_args=(-3, 0.0)
Trying (typ, c_byte) ...
    *FAILED* result=-3.0; got_args=(3.1400000000000001, -3)
Trying (c_byte, typ, typ) ...
    *FAILED* result=-inf; got_args=(-3, nan, -inf)
Trying (typ, typ) ...
    WORKED result=3.14; got_args=(3.1400000000000001, 3.1400000000000001)
Trying (c_double, typ) ...
    *FAILED* result=0.0; got_args=(3.1400000000000001, 0.0)
trying (c_int, typ) ...
    *FAILED* result=0.0; got_args=(-3, 0.0)
trying (c_long, typ) ...
    *FAILED* result=0.0; got_args=(-3, 0.0)
trying (c_longlong, typ) ...
    *FAILED* result=0.0; got_args=(-3, 0.0)

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6029>
_______________________________________

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: [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: [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:25 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:25:25 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <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:25:44 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:25:44 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242858344.56.0.427213091188.issue6075@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


Added file: http://bugs.python.org/file14027/Bindings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 00:26:01 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:26:01 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242858361.0.0.418007904325.issue6075@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


Added file: http://bugs.python.org/file14028/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 00:33:30 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:33:30 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242858810.05.0.832512796005.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

These patches were tested on Python/IDLE 2.6.2 and Tk version 8.5.7. My 
build of Tk, which runs on top of Cocoa, is based on a fork of Tk hosted 
at http://github.com/das/tcltk/tree/de-carbon-8-5. Tk-Cocoa will become 
the main line for Mac OS X in Tk 8.6, now in beta. I have not tested these 
patches with a standard build of Tk-Carbon, but the patches default to the 
current IDLE behavior if Tk-Cocoa is not detected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 00:52:17 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 20 May 2009 22:52:17 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1242859937.51.0.654540902399.issue6064@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Attaching a patch against trunk (at revision 72805).

----------
keywords: +patch
Added file: http://bugs.python.org/file14029/threading.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Thu May 21 00:54:11 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 20 May 2009 22:54:11 +0000
Subject: [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 02:42:08 2009
From: report at bugs.python.org (higstar)
Date: Thu, 21 May 2009 00:42:08 +0000
Subject: [issue6068] c_ulonglong structure members appear read-only
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1242866528.52.0.762564183475.issue6068@psf.upfronthosting.co.za>


higstar <adrian at higstar.com> added the comment:

Right...I've just found a caveat in section 16.15.1.12 of the html
documentation which means this should be a feature request:

"Bit fields are only possible for integer fields"

----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Thu May 21 02:43:43 2009
From: report at bugs.python.org (higstar)
Date: Thu, 21 May 2009 00:43:43 +0000
Subject: [issue6069] casting error from ctypes array to structure
In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za>
Message-ID: <1242866623.03.0.42045536953.issue6069@psf.upfronthosting.co.za>


higstar <adrian at higstar.com> added the comment:

After reading the documentation for ctypes (specifically "Bit fields are
only possible for integer fields" from section 16.15.1.12) I've updated
the test.

---
import ctypes
import time

class uint(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint, 31),
                   ("Data1",   ctypes.c_uint, 32),
                   ]

class ulonglong(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_ulonglong, 31),
                   ("Data1",   ctypes.c_ulonglong, 32),
                  ]

size_of_structures_in_bytes = 8

def castbytes(type):
    buffer = (ctypes.c_byte * size_of_structures_in_bytes)()
    for index in range(size_of_structures_in_bytes):
        buffer[index] = 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 = [ uint, 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 == 0x2AAAAAAA:
    Failed = True
    print("Data0 failed")
if not tests[0].Data1 == tests[1].Data1 == 0xAAAAAAAA:
    Failed = True
    print("Data1 failed")

if not Failed:
    print("Passed")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6069>
_______________________________________

From report at bugs.python.org  Thu May 21 02:44:38 2009
From: report at bugs.python.org (higstar)
Date: Thu, 21 May 2009 00:44:38 +0000
Subject: [issue6068] support read/write c_ulonglong type bitfield structures
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1242866678.91.0.733040645479.issue6068@psf.upfronthosting.co.za>


Changes by higstar <adrian at higstar.com>:


----------
title: c_ulonglong structure members appear read-only -> support read/write c_ulonglong type bitfield structures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Thu May 21 02:54:12 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 00:54:12 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242867252.24.0.923196399341.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

This updated patch of macosxSupport.py adds a fix that addresses the 
preferences dialog, see http://bugs.python.org/issue5232.

----------
Added file: http://bugs.python.org/file14031/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 02:54:20 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 00:54:20 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242867261.0.0.606332243942.issue6075@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14028/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 02:59:06 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 00:59:06 +0000
Subject: [issue5232] Setting font from preference dialog in IDLE on OS X broken
In-Reply-To: <1234476506.45.0.29629224735.issue5232@psf.upfronthosting.co.za>
Message-ID: <1242867546.61.0.631269976375.issue5232@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Added Brad's snippet to macosxSupport.py: see http://bugs.python.org/issue6075

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5232>
_______________________________________

From report at bugs.python.org  Thu May 21 03:40:38 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Thu, 21 May 2009 01:40:38 +0000
Subject: [issue5232] Setting font from preference dialog in IDLE on OS X broken
In-Reply-To: <1234476506.45.0.29629224735.issue5232@psf.upfronthosting.co.za>
Message-ID: <1242870038.78.0.466641535269.issue5232@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Superceeded by 6075.

----------
assignee:  -> kbk
nosy: +kbk
resolution:  -> later
status: open -> closed
superseder:  -> Patch for IDLE/OS X to work with Tk-Cocoa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5232>
_______________________________________

From report at bugs.python.org  Thu May 21 05:10:25 2009
From: report at bugs.python.org (higstar)
Date: Thu, 21 May 2009 03:10:25 +0000
Subject: [issue6068] support read/write c_ulonglong type bitfield structures
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1242875425.38.0.422322671534.issue6068@psf.upfronthosting.co.za>


higstar <adrian at higstar.com> added the comment:

I added the following to test_bitfields.py and got the results listed below:
def test_ulonglong_crossing_32_boundary(self):
    class X(BigEndianStructure):
        _fields_ = [("a", c_ulonglong, 16),
                    ("b", c_ulonglong, 32),
                    ("c", c_ulonglong, 16)]

    x = X()
    self.failUnlessEqual((x.a, x.b, x.c), (0, 0, 0))
    x.a, x.b, x.c = 1, 1, 1
    self.failUnlessEqual((x.a, x.b, x.c), (1, 1, 1))

======================================================================
FAIL: test_ulonglong_crossing_32_boundary (__main__.BitFieldTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "W:\ctypes\build\lib.win32-2.6\ctypes\test\test_bitfields.py",
line 98, in test_ulonglong_crossing_32_boundary
    self.failUnlessEqual((x.a, x.b, x.c), (1, 1, 1))
AssertionError: (1L, 0L, 1L) != (1, 1, 1)

----------------------------------------------------------------------
Ran 16 tests in 0.015s

FAILED (failures=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Thu May 21 12:55:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 May 2009 10:55:11 +0000
Subject: [issue6077] Unicode issue with tempfile on Windows
In-Reply-To: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>
Message-ID: <1242903311.53.0.310620042794.issue6077@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6077>
_______________________________________

From report at bugs.python.org  Thu May 21 15:01:37 2009
From: report at bugs.python.org (Yonas)
Date: Thu, 21 May 2009 13:01:37 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1242910897.34.0.00772018747223.issue4434@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Ralf,

Linking against the static library (with '-Xlinker -export-dynamic') did
_not_ solve the problem for me.

gcc `python2.6-config --cflags` -c -fPIC mylib.c -o mylib.o -Xlinker
-export-dynamic

gcc -Xlinker -export-dynamic -lpthread -ldl -lutil -lm -lz -shared
-Wl,-soname,mylib.so -o mylib.so  mylib.o 
/usr/lib/python2.6/config/libpython2.6.a

gcc `python2.6-config --cflags` -Xlinker -export-dynamic -ldl -lutil -lm
-lz  -o main main.c /usr/lib/python2.6/config/libpython2.6.a
----------------------

`python2.6-config --cflags` returns
-I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing
-DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes

--------
Ubuntu Jaunty
Linux yonas-laptop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59
UTC 2009 i686 GNU/Linux

----------
nosy: +yonas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu May 21 15:03:54 2009
From: report at bugs.python.org (Yonas)
Date: Thu, 21 May 2009 13:03:54 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1242911034.57.0.312608979233.issue4434@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Same error message: 

import dl: ImportError: /usr/lib/python2.6/lib-dynload/dl.so: undefined
symbol: PyExc_ValueError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu May 21 15:15:54 2009
From: report at bugs.python.org (Yonas)
Date: Thu, 21 May 2009 13:15:54 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1242911754.79.0.963537707803.issue4434@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Here's my log file (`LD_DEBUG=all ./main`)

----------
Added file: http://bugs.python.org/file14033/log-main.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu May 21 16:10:36 2009
From: report at bugs.python.org (Yonas)
Date: Thu, 21 May 2009 14:10:36 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1242915036.58.0.546130851517.issue4434@psf.upfronthosting.co.za>


Changes by Yonas <yonas.y at gmail.com>:


Removed file: http://bugs.python.org/file14033/log-main.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu May 21 16:12:16 2009
From: report at bugs.python.org (Yonas)
Date: Thu, 21 May 2009 14:12:16 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1242915136.39.0.563093420545.issue4434@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Updated log file.

----------
Added file: http://bugs.python.org/file14034/log-main.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

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: [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 16:44:27 2009
From: report at bugs.python.org (mkv)
Date: Thu, 21 May 2009 14:44:27 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1242917067.53.0.223941172582.issue6054@psf.upfronthosting.co.za>


mkv <mvirkkil at cc.hut.fi> added the comment:

I'm creating a debian package (.deb) for a system which uses busybox's
dpkg. A deb is an ar-archive (not tar, unix ar) archive, which in turn
contains two tar archives. dpkg will first extract a tar archive called
control.tar.gz (or bz2) from the package, and from that tar it will
extract a file stored with the path "./control". 

The problem is that with the current implementation of tarfile it's
impossible to create a tar archive which would contain a file stored
with the path "./control". This means it's impossible to use tarfile to
create deb packages which would work with busybox' dpkg. 

I'm not 100% sure if that precise path is requirement of the deb file
format, or if it is because of how busybox' dpkg is implemented. However
I have not seen a packaging guide or a deb package which wouldn't have
the control file stored as ./control in the tar archive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From report at bugs.python.org  Thu May 21 16:50:11 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 14:50:11 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242917411.69.0.674581072779.issue6075@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14031/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 16:51:26 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 14:51:26 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242917486.36.0.289556302364.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

additional refinement to help_dialog command, makes menu consistent

----------
Added file: http://bugs.python.org/file14035/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 16:53:24 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 14:53:24 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242917604.39.0.255792400993.issue6075@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14035/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 16:53:44 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 21 May 2009 14:53:44 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1242917624.06.0.875523530694.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

typo in macosxSupport.patch--fixed

----------
Added file: http://bugs.python.org/file14036/macosxSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu May 21 17:13:56 2009
From: report at bugs.python.org (Yonas)
Date: Thu, 21 May 2009 15:13:56 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1242918836.27.0.845197089706.issue4434@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

rb's workaround works, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Thu May 21 18:07:47 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 21 May 2009 16:07:47 +0000
Subject: [issue5064] compiler.parse raises SyntaxErrors without line number
	information
In-Reply-To: <1232940344.37.0.615917855536.issue5064@psf.upfronthosting.co.za>
Message-ID: <1242922067.57.0.115694799322.issue5064@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

It seems a patch would be an enormous undertaking, as the data structure
returned by the parser does not include this information, and the parser
is written in C.

I'll just hack around this somehow.  Don't expect a patch from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5064>
_______________________________________

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: [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 19:20:22 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Thu, 21 May 2009 17:20:22 +0000
Subject: [issue6079] SyntaxError in xmlrpc.client Fault example
In-Reply-To: <1242922319.61.0.524994134376.issue6079@psf.upfronthosting.co.za>
Message-ID: <1242926422.81.0.303472244743.issue6079@psf.upfronthosting.co.za>


Thijs Triemstra <lists at collab.nl> added the comment:

On the same documentation page for Python 3.1b1 it shows a similar error 
for the ProtocolError example:

import xmlrpc.client

# create a ServerProxy with an invalid URI
proxy = xmlrpc.client.ServerProxy("http://invalidaddress/")

try:
    proxy.some_method()
except xmlrpc.client.ProtocolError, err:
    print("A protocol error occurred")
    print("URL: %s" % err.url)
    print("HTTP/HTTPS headers: %s" % err.headers)
    print("Error code: %d" % err.errcode)
    print("Error message: %s" % err.errmsg)

Throws this error:

  File "proto.py", line 8
    except xmlrpc.client.ProtocolError, err:
                                      ^
SyntaxError: invalid syntax

Which should be fixed with:

import xmlrpc.client

# create a ServerProxy with an invalid URI
proxy = xmlrpc.client.ServerProxy("http://invalidaddress/")

try:
    proxy.some_method()
except xmlrpc.client.ProtocolError as err:
    print("A protocol error occurred")
    print("URL: %s" % err.url)
    print("HTTP/HTTPS headers: %s" % err.headers)
    print("Error code: %d" % err.errcode)
    print("Error message: %s" % err.errmsg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6079>
_______________________________________

From report at bugs.python.org  Thu May 21 19:22:18 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Thu, 21 May 2009 17:22:18 +0000
Subject: [issue6079] SyntaxError in xmlrpc.client examples
In-Reply-To: <1242922319.61.0.524994134376.issue6079@psf.upfronthosting.co.za>
Message-ID: <1242926538.24.0.678236143166.issue6079@psf.upfronthosting.co.za>


Thijs Triemstra <lists at collab.nl> added the comment:

Updated ticket title since it's for multiple sections in the 
documentation, not just the Fault example.

----------
title: SyntaxError in xmlrpc.client Fault example -> SyntaxError in xmlrpc.client examples

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6079>
_______________________________________

From report at bugs.python.org  Thu May 21 22:25:10 2009
From: report at bugs.python.org (Clifford W Johnson)
Date: Thu, 21 May 2009 20:25:10 +0000
Subject: [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: <1242937510.08.0.35248517538.issue6029@psf.upfronthosting.co.za>


Clifford W Johnson <Clifford at IEEE.org> added the comment:

Turns out the problem is really in the Sparc version of libffi -- the 
ffi_closure_sparc_inner_v9 function in 
Modules/_ctypes/libffi/src/sparc/ffi.c wasn't properly accounting for 
the 16-byte alignment of a long double in an argument stack -- it 
presumed 8-byte alignment throwing off any long double value after a 
shorter value.  (16-byte alignment is specified in the SPARC Compliance 
Definition.)

I've attached a patch which I'm sure could be improved (there's 
probably a more proper way to do things in libffi) but it passes the 
check tests for ctypes and a few other tests I threw in.


By the way, I noticed that one of the test cases in the script I added 
in my last comment has an error in its success/failure test ... 
the "(typ, c_byte)" test should check for the result of -3 instead of 
3.14.

----------
keywords: +patch
Added file: http://bugs.python.org/file14037/sparc_longdouble.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6029>
_______________________________________

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: [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  Thu May 21 22:39:07 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 May 2009 20:39:07 +0000
Subject: [issue6080] Itertools objects are missing "send"
In-Reply-To: <1242938060.5.0.00936464962761.issue6080@psf.upfronthosting.co.za>
Message-ID: <1242938347.81.0.561616360914.issue6080@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Why would they?  There is no use case (the data would be thrown away). 
Not every iterator has to support the whole generator protocol.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6080>
_______________________________________

From report at bugs.python.org  Thu May 21 23:24:37 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 21 May 2009 21:24:37 +0000
Subject: [issue6080] Itertools objects are missing "send"
In-Reply-To: <1242938060.5.0.00936464962761.issue6080@psf.upfronthosting.co.za>
Message-ID: <1242941077.62.0.143910354015.issue6080@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

My bad, thought that every iterator is supposed to implement "send".
I still think that "count" and "repeat" can support and use it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6080>
_______________________________________

From report at bugs.python.org  Thu May 21 23:27:46 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 21 May 2009 21:27:46 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1242941266.32.0.338258036818.issue6064@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I think that 
    self.__daemonic = daemon or self._set_daemon()
is wrong, need to thing about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Thu May 21 23:30:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 May 2009 21:30:28 +0000
Subject: [issue6080] Itertools objects are missing "send"
In-Reply-To: <1242938060.5.0.00936464962761.issue6080@psf.upfronthosting.co.za>
Message-ID: <1242941428.83.0.0283278143858.issue6080@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

What do you have in mind for count() or repeat()?  How would they use
the send() value?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6080>
_______________________________________

From report at bugs.python.org  Fri May 22 00:23:29 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 21 May 2009 22:23:29 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1242944609.11.0.0835314229575.issue6042@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I've fixed #1689458. Here's a new version of the patch with the
simplifying tweaks to PyCode_CheckLineNumber() so y'all can see what
that looks like.

If I don't get any substantive comments by the weekend (thanks Antoine
for the docs +1 :), I'll assume I've looked at this code longer than
anyone in the last 7 years and commit it. :)

----------
Added file: http://bugs.python.org/file14038/lnotab.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Fri May 22 00:57:54 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 May 2009 22:57:54 +0000
Subject: [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: <1242946674.41.0.452915317112.issue6072@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 72812.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6072>
_______________________________________

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: [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: [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 03:45:55 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 22 May 2009 01:45:55 +0000
Subject: [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: <1242956755.11.0.776171763529.issue6082@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

They are the same file, namely your tty

Python 2.6 (r26:66714, Oct  8 2008, 22:16:30) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> [os.ttyname(fp.fileno()) for fp in sys.stdin, sys.stdout, sys.stderr]
['/dev/ttys002', '/dev/ttys002', '/dev/ttys002']

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6082>
_______________________________________

From report at bugs.python.org  Fri May 22 03:52:31 2009
From: report at bugs.python.org (higstar)
Date: Fri, 22 May 2009 01:52:31 +0000
Subject: [issue6069] casting error from ctypes array to structure
In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za>
Message-ID: <1242957151.76.0.64046579619.issue6069@psf.upfronthosting.co.za>


higstar <adrian at higstar.com> added the comment:

Another example of this:
---
import ctypes

correct_data_dict = {
                     'Data0' : 0x55555555,
                     'Data1' : 0x02,
                     'Data2' : 0x0AAA,
                     }

class closest_fit(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint8, 3),
                   ("Data2",   ctypes.c_uint16, 12),
                  ]


class closest_fit_min_16(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint16, 3),
                   ("Data2",   ctypes.c_uint16, 12),
                  ]

class closest_fit_min_32(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint32, 3),
                   ("Data2",   ctypes.c_uint32, 12),
                  ]

class uint32(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint32, 3),
                   ("Data2",   ctypes.c_uint32, 12),
                  ]

class uint64(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint64, 32),
                   ("Data1",   ctypes.c_uint64, 3),
                   ("Data2",   ctypes.c_uint64, 12),
                  ]

size_of_structures_in_bytes = 6

def castbytes(type):
    buffer = (ctypes.c_byte * size_of_structures_in_bytes)()
    for index in range(size_of_structures_in_bytes):
        buffer[index] = 0x55
    return ctypes.cast(ctypes.pointer(buffer),
ctypes.POINTER(type)).contents

def print_members(test):
    print("Data0 is 0x%X, Data1 is 0x%X, Data2 is 0x%X for
%s"%(test.Data0, test.Data1, test.Data2, test.__class__.__name__))



test_classes = [closest_fit, uint32, closest_fit_min_16,
closest_fit_min_32, uint64]

Test_Failed = False
tests = [castbytes(type) for type in test_classes]
for test in tests:
#    print_members(test)
    for data in correct_data_dict:
        if not test.__getattribute__(data) == correct_data_dict[data]:
            Test_Failed = True
            print("%s failed for %s, value was 0x%X but should have been
0x%X"%(data, test.__class__.__name__, test.__getattribute__(data),
correct_data_dict[data]))

if not Test_Failed:
    print("Passed")
---
>c:\python25\python.exe IssueNEW.py
Data2 failed for closest_fit, value was 0x550 but should have been 0xAAA

>c:\python26\python.exe IssueNEW.py
Data2 failed for closest_fit, value was 0x550 but should have been 0xAAA

>c:\python30\python.exe IssueNEW.py
Data2 failed for closest_fit, value was 0x550 but should have been 0xAAA

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6069>
_______________________________________

From report at bugs.python.org  Fri May 22 03:58:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 May 2009 01:58:45 +0000
Subject: [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: <1242957525.86.0.388828068854.issue6082@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6082>
_______________________________________

From report at bugs.python.org  Fri May 22 05:12:23 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 22 May 2009 03:12:23 +0000
Subject: [issue6057] sqlite3 error classes should be documented
In-Reply-To: <1242858609.44.0.240600294741.issue6057@psf.upfronthosting.co.za>
Message-ID: <p06240801c63bbc605d2a@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

Thanks for the informatiion about the exception classes documented in the PEP. I didn't mean to suggest that the information wasn't available. (For that matter,  I was able to extract it for my purposes by looking at the .c source.) I've been writing a book on "Bioinformatics Programming Using Python" for O'Reilly and working my way through the documentation for the many modules I describe in detail paying far more attention to accuracy, completeness, etc. than  would normally concern me. In the process I have submitted many observations about inaccuracies, inconsistencies, gaps, etc. in the library documentation. In effect I am doing a "review" and picking up problems in a module documentation that could easily go unnoticed by anyone familiar with the modules. A small portion have involved incomplete transitions from Python 2 to Python 3. (My book uses 3; anyone involved in module documentation should take my comments as QA observations about Python 3 documentation and decide what, if anything, to do about them.)

My concern is for non-developer Python programmers who expect module documentation to be self-contained except, perhaps, where there are pointers to major outside resources (for instance, sqlite.org documentation). I don't think we can ask or expect "normal" Python programmers to know what a PEP is, how to access it, what relationship a PEP has to the module as implemented, etc.  True, for the particular case of the DB API interface the PEP document is more important than most becuase it defines an interface that other modules implement. In this case, perhaps the best approach would be to document the DB-API as part of the ordinary Python library documentation, then have sqlite3 be a subtopic of that. However it's done I think user's should be able to read the standard documentation and find what they need. An incidental reason is that people sometimes work offline and don't have access to the PEPs though they do have access to the installed documentation.

All those arguments aside, perhaps what makes the most sense is to simply add the error hierarchy following "This is the exception inheritance layout:" to the sqlite documentation, while still referring the reader to the PEP. I am just really wary of having PEPs serve as documentation for ordinary Python programmers. Even many PEPs that have been accepted and implemented have more interest as background and explanation than practical documentation, snce the documentation of their contribution to the language and the library has been integrated into the regular documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6057>
_______________________________________

From report at bugs.python.org  Fri May 22 05:35:03 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Fri, 22 May 2009 03:35:03 +0000
Subject: [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: <1242963303.41.0.277586330223.issue6082@psf.upfronthosting.co.za>


Ryan Leslie <rylesny at gmail.com> added the comment:

Thanks for the quick response, Philip. Makes even more sense now that I see:

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.
>>> open('/dev/stdout').readline()
hello
'hello\n'
>>> open('/dev/stdin').readline()
hello
'hello\n'
>>>

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6082>
_______________________________________

From report at bugs.python.org  Fri May 22 05:35:31 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Fri, 22 May 2009 03:35:31 +0000
Subject: [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: <1242963331.71.0.222175706034.issue6082@psf.upfronthosting.co.za>


Changes by Ryan Leslie <rylesny at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6082>
_______________________________________

From report at bugs.python.org  Fri May 22 06:21:40 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 May 2009 04:21:40 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1242966100.94.0.996788852311.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks very much for the tips Martin.

I cleaned up the function per your suggestions.  I also implemented
islink by setting two flags in st_mode if the file is a symlink.  The
implementation was a little convoluted, but it might just work.

The current patch does compile for me with just a few compiler warnings,
which I hope can be easily shaken out.

..\..\Modules\posixmodule.c(4794) : warning C4013: 'CreateSymbolicLink'
undefined; assuming extern returning int
..\..\Modules\posixmodule.c(4803) : warning C4133: 'function' :
incompatible types - from 'PyObject *' to 'char *'
..\..\Modules\posixmodule.c(7174) : warning C4113: 'PyObject *(__cdecl
*)(PyObject *,PyObject *,PyObject *)' differs in parameter lists from
'PyCFunction'

The first warning might be a problem.  I understand from the docs
(http://msdn.microsoft.com/en-us/library/aa363866.aspx) that all I need
to do is include windows.h, which is already included... but still the
function prototype isn't present.  This might be because a preprocessor
declaration of WINVER isn't set high enough... but since the same
executable is built for all versions of Windows, how is this reconciled
in the compiler?

----------
Added file: http://bugs.python.org/file14039/windows symlink draft 2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri May 22 10:01:31 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 May 2009 08:01:31 +0000
Subject: [issue6078] freeze.py doesn't work
In-Reply-To: <1242916100.37.0.236967212575.issue6078@psf.upfronthosting.co.za>
Message-ID: <1242979291.13.0.839884934198.issue6078@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The problem is that the warnings module's init function does not adhere
to the standard Python naming scheme for extension modules: it's called
_PyWarnings_Init rather than init_warnings. This C helper module was
added to Python 2.6.

OTOH, warnings is a builtin module which always gets imported, so the
import mechanism bypasses the normal scan for such functions.

In order to get freeze to work, it should be enough to add '_warnings'
to the list never in makeconfig.py of the freeze tool.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6078>
_______________________________________

From report at bugs.python.org  Fri May 22 10:18:57 2009
From: report at bugs.python.org (Bill McCloskey)
Date: Fri, 22 May 2009 08:18:57 +0000
Subject: [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: [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 11:23:02 2009
From: report at bugs.python.org (bones7456)
Date: Fri, 22 May 2009 09:23:02 +0000
Subject: [issue6084] documentation of zip function is error
In-Reply-To: <1242983871.03.0.567968513766.issue6084@psf.upfronthosting.co.za>
Message-ID: <1242984182.85.0.313761419665.issue6084@psf.upfronthosting.co.za>


bones7456 <bones7456 at gmail.com> added the comment:

>>> type(x)
<type 'list'>
>>> type(x2)
<type 'tuple'>

It cann't be equal...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6084>
_______________________________________

From report at bugs.python.org  Fri May 22 11:33:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 May 2009 09:33:34 +0000
Subject: [issue6084] documentation of zip function is error
In-Reply-To: <1242983871.03.0.567968513766.issue6084@psf.upfronthosting.co.za>
Message-ID: <1242984814.64.0.415293688563.issue6084@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r72822.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6084>
_______________________________________

From report at bugs.python.org  Fri May 22 11:35:00 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 May 2009 09:35:00 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1242984900.75.0.181214689611.issue5756@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Reopening as RELEASE BLOCKER.

r71936 does indeed install pydoc and idle with a 3 suffix.  However, it 
also removed the 2to3 and smtp.py scripts previously installed by 
setup.py without providing any replacements for them, versioned or not.

Section 25.4.1 of the 3.1 Standard Library docs state "2to3 will usually 
be installed with the Python interpreter as a script. It is also located 
in the Tools/scripts directory of the Python root."

In the case of the OSX installer, as it stands now with r71936, there is 
no longer a 2to3 script in the framework bin directory and Tools/scripts 
is not installed.  So what's a user to do?  Is this also an issue for 
the Windows installers?  What about Linux/Unix distributions?  (For the 
OSX installer, I've also documented the problem in Issue5272).

This raises the issues of what is a sensible way to handle potential 
multiple versions of 2to3. Perhaps this has been discussed and decided 
elsewhere?  If not ...:

I see two scenarios of interest -

1. If a user has installed 2.6 (or newer 2.x), a 2to3 is already 
installed. But installing 3.x will(for 3.0)/should(for 3.1) install a 
3.x 2to3 script.  Should it supersede, co-exist with, or defer to the 
2.x version?

2. If a user is moving from 2.5 or earlier, to 3.x, the 3.x installation 
needs to unconditionally provide 2to3.

In the case of the interpreter, the reason for renaming to python3 is 
clear: python2 and python3 expect different input, produce different 
output, and need to co-exist.  In the case of 2to3, however, there 
shouldn't be any fundamental differences between the versions provided 
with a py2 or a py3 install other than bug fixes and potential new 
features, right?

If so, since the output of 2to3 is python3, one could make the case that 
the py3 installed 2to3 should take precedence over a py2 one, at least 
by default.  If there is the potential need for the user to be able to 
choose which 2to3 to use, then a user-friendly solution would be to have 
py2 and py3 install them as something like 2to3-2 and 2to3-3, 
respectively, and a 2to3 which would prefer 2to3-3 but fall back to 
2to3-2.  Otherwise, the py3k version could always just install as 2to3-3 
and it would be up to the user to know (with documentation help) about 
the potential two versions, since the py2 2to3 version is already out of 
the bag and in the field.  Or the py3 install could unilaterally 
supersede a py2 version, with the limitation that a new 2.6.x (re-
)install would likely cause a 2to3 revert, something that could be fixed 
in 2.7.

In any case, if this hasn't already happened, I think a decision needs 
to be made on how the 2to3 conflict should be handled so that at least 
*one* version of 2to3 is always available, ensuring that the solution 
makes sense for all of the major platforms, and making sure it gets 
implemented *and* properly documented prior to 3.1 release and, if 
necessary, the 2.7 release.

I'm less concerned about the removal of the smtpd.py script as I suspect 
it is little used and I don't know how it is handled by the all of the 
platforms (the OSX installer has provided it in bin up until now).  Does 
the smtpd script even appear in the documentation anywhere?  
Nevertheless, if it hasn't already happened, the impact of its removal 
should be assessed on the major platforms and, if it remains removed, at 
least that should be documented in What's New.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

From report at bugs.python.org  Fri May 22 11:39:54 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 May 2009 09:39:54 +0000
Subject: [issue5272] OS X installer: fix makefile target changed for 3.x
In-Reply-To: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
Message-ID: <1242985194.75.0.230216107743.issue5272@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the decision to have references to py3k scripts always contain a 
"3", I agree that "make fullinstall" is no longer appropriate.

With r72723 and current py3k, however, there are still some issues.  
Compare ls -l bin from 2.6.2, 3.0.1, and current py3k:

$ cd /Library/Frameworks/Python.framework/Versions
$ ls -l 2.6/bin
total 264
-rwxrwxr-x  1 root  admin    150 Apr 16 00:28 2to3*
lrwxr-xr-x  1 root  admin      7 May 21 23:57 idle@ -> idle2.6
-rwxrwxr-x  1 root  admin    138 Apr 16 00:28 idle2.6*
lrwxr-xr-x  1 root  admin      8 May 21 23:57 pydoc@ -> pydoc2.6
-rwxrwxr-x  1 root  admin    123 Apr 16 00:28 pydoc2.6*
lrwxr-xr-x  1 root  admin      9 May 21 23:57 python@ -> python2.6
lrwxr-xr-x  1 root  admin     16 May 21 23:57 python-config@ -> 
python2.6-config
-rwxrwxr-x  1 root  admin  33688 Apr 16 00:30 python2.6*
-rwxrwxr-x  1 root  admin   1463 Apr 16 00:29 python2.6-config*
lrwxr-xr-x  1 root  admin     10 May 21 23:57 pythonw@ -> pythonw2.6
-rwxrwxr-x  1 root  admin  33688 Apr 16 00:30 pythonw2.6*
lrwxr-xr-x  1 root  admin     11 May 21 23:57 smtpd.py@ -> smtpd2.6.py
-rwxrwxr-x  1 root  admin  18093 Apr 16 00:28 smtpd2.6.py*

$ ls -l 3.0/bin
total 248
-rwxrwxr-x  1 root  admin    150 Feb 14 10:04 2to3*
lrwxr-xr-x  1 root  admin      7 May 21 23:58 idle@ -> idle3.0
-rwxrwxr-x  1 root  admin    138 Feb 14 10:04 idle3.0*
lrwxr-xr-x  1 root  admin      8 May 21 23:58 pydoc@ -> pydoc3.0
-rwxrwxr-x  1 root  admin    123 Feb 14 10:04 pydoc3.0*
lrwxr-xr-x  1 root  admin      9 May 21 23:58 python@ -> python3.0
lrwxr-xr-x  1 root  admin     16 May 21 23:58 python-config@ -> 
python3.0-config
-rwxrwxr-x  1 root  admin  29560 Feb 14 10:05 python3.0*
-rwxrwxr-x  1 root  admin   1440 Feb 14 10:05 python3.0-config*
lrwxr-xr-x  1 root  admin     10 May 21 23:58 pythonw@ -> pythonw3.0
-rwxrwxr-x  1 root  admin  29560 Feb 14 10:05 pythonw3.0*
lrwxr-xr-x  1 root  admin     11 May 21 23:58 smtpd.py@ -> smtpd3.0.py
-rwxrwxr-x  1 root  admin  18119 Feb 14 10:04 smtpd3.0.py*

$ ls -l 3.1/bin
total 272
lrwxr-xr-x  1 root  admin      7 May 21 19:10 idle3@ -> idle3.1
-rwxrwxr-x  1 root  admin    138 May 21 18:51 idle3.1*
lrwxr-xr-x  1 root  admin      8 May 21 19:10 pydoc3@ -> pydoc3.1
-rwxrwxr-x  1 root  admin    123 May 21 18:51 pydoc3.1*
-rwxrwxr-x  1 root  admin  34220 May 21 18:51 python*
lrwxr-xr-x  1 root  admin     16 May 21 19:10 python-config@ -> 
python3.1-config
lrwxr-xr-x  1 root  admin      9 May 21 19:10 python3@ -> python3.1
lrwxr-xr-x  1 root  admin     16 May 21 19:10 python3-config@ -> 
python3.1-config
-rwxrwxr-x  1 root  admin  29560 May 21 18:51 python3.1*
-rwxrwxr-x  1 root  admin   1440 May 21 18:51 python3.1-config*
lrwxr-xr-x  1 root  admin     10 May 21 19:10 pythonw3@ -> pythonw3.1
-rwxrwxr-x  1 root  admin  29560 May 21 18:51 pythonw3.1*

Issues:

1. In py3k bin, there is a "python" binary rather than the symlink that 
was there before.  That appears to be the unstripped binary of the 
interpreter (before it is stripped installed into the fw app bundle). 
Presumably the symlink install used to implicitly remove the binary; now 
an explicit rm is needed?

2. There is still a symlink to python-config.

3. There is no longer *any* 2to3 script, versioned or not. r71936  
(setup.py) is the culprit here (Issue5756, which I'm reopening to ensure 
this issue is examined for all platforms).  With regard to the OSX 
installer, since Tools/scripts isn't installed, there needs to be a 
script of some kind in bin.  As discussed in Issue5756, it should be 
decided how to resolve conflicts between a py2 2to3 and a py3 one.

4. There is no longer any smtpd.py or smtpd3.x.py script/link installed, 
also due to r71936 (setup.py) and to r72723 (Mac/Makefile.in).  I don't 
see this as a huge issue since I doubt that script is used much at all.  
But, at the least, a NEWS/What's New and/or README item about its 
removal in 3.1 is in order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________

From report at bugs.python.org  Fri May 22 12:06:48 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 22 May 2009 10:06:48 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1242986808.27.0.00117502408512.issue5756@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: the 2to3 is not installed anymore by the main makefiles, I don't know 
why.

I'm actually happy that smtpd.py isn't installed anymore, this always 
looked more like an example that a real tool to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

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: [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: [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 12:30:18 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Fri, 22 May 2009 10:30:18 +0000
Subject: [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: <1242988218.16.0.174148751322.issue6086@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14041/doc_typo_trunk_may_22_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6086>
_______________________________________

From report at bugs.python.org  Fri May 22 12:30:41 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Fri, 22 May 2009 10:30:41 +0000
Subject: [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: <1242988241.21.0.422665350053.issue6086@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


Added file: http://bugs.python.org/file14042/doc_typo_py3k_may_22_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6086>
_______________________________________

From report at bugs.python.org  Fri May 22 12:30:41 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 May 2009 10:30:41 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1242988241.52.0.105538427491.issue5756@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ronald, no changes were made to the makefiles, just to setup.py in 
r71400 and r71936 (which also renamed idle and pydoc):

[...]
Modified: python/branches/py3k/setup.py
========================================================================
======
--- python/branches/py3k/setup.py	(original)
+++ python/branches/py3k/setup.py	Sat Apr 25 23:11:45 2009
@@ -1652,13 +1652,7 @@
           # called unless there's at least one extension module 
defined.
           ext_modules=[Extension('_struct', ['_struct.c'])],
 
-          # Scripts to install
-          # Commented out because we don't want them to override the 
2.x
-          # ones. See #1590.
-          scripts = []
-          #scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
-          #           'Tools/scripts/2to3',
-          #           'Lib/smtpd.py']
+          scripts = ["Tools/scripts/pydoc3", "Tools/scripts/idle3"]
         )
 
 # --install-platlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

From report at bugs.python.org  Fri May 22 12:44:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 May 2009 10:44:45 +0000
Subject: [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: <1242989085.64.0.433952254794.issue6086@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in trunk r72830 and py3k r72831. Thanks!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6086>
_______________________________________

From report at bugs.python.org  Fri May 22 12:47:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 May 2009 10:47:10 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1242989230.09.0.95596932515.issue5756@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, my assertion "no changes were made to the makefiles" is not quite 
correct.  r71372 did change the altinstall target for Issue1590, the 
precipitator of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

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: [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: [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:09:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 May 2009 16:09:30 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1243008570.2.0.134654625148.issue6042@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure why you changed PyCode_CheckLineNumber to
_PyCode_CheckLineNumber. Other than that, I suppose you know what you're
doing :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Fri May 22 18:12:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 May 2009 16:12:44 +0000
Subject: [issue6088] Python3.0.1.1 is not available when system locale is
	zh_TW.eucTW
In-Reply-To: <1243007545.21.0.68248439701.issue6088@psf.upfronthosting.co.za>
Message-ID: <1243008764.2.0.335056435324.issue6088@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can't reproduce this on trunk (or 3.0 maint) on Gentoo Linux:

~/python/py3k>./python
Python 3.1b1+ (py3k:72816, May 21 2009, 22:01:55) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[50411 refs]
>>> locale.getlocale()
('zh_TW', 'eucTW')
[50423 refs]
>>> help()

Welcome to Python 3.1!  This is the online help utility.

[...]

>>> locale.setlocale(locale.LC_ALL, '')
'zh_TW.eucTW'
[50462 refs]
>>> help()

Welcome to Python 3.1!  This is the online help utility.

[...]

Leon: you say ActivePython, which is a vendor distribution.  I think you
should report this bug to them, unless you can reproduce it using the
python.org python.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> pending
type: crash -> behavior

_______________________________________
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: [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:26:05 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 22 May 2009 16:26:05 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1243009565.07.0.795273403472.issue6042@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I had two reasons to change PyCode_CheckLineNumber to
_PyCode_CheckLineNumber: First, its behavior is changing without its
signature changing. Without a name change, that could break users
silently (if there are any codesearch missed). Second, I think it's an
internal function which we should feel free to change again if it makes
the implementation cleaner. In order to let people change it at will, it
should start with "_Py".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Fri May 22 18:44:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 May 2009 16:44:16 +0000
Subject: [issue6079] SyntaxError in xmlrpc.client examples
In-Reply-To: <1242922319.61.0.524994134376.issue6079@psf.upfronthosting.co.za>
Message-ID: <1243010656.71.0.078698319321.issue6079@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r72832.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6079>
_______________________________________

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: [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 report at bugs.python.org  Fri May 22 18:52:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 May 2009 16:52:59 +0000
Subject: [issue6089] str.format raises SystemError
In-Reply-To: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>
Message-ID: <1243011179.56.0.983665071733.issue6089@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

trunk and py3k debug build gives this:

>>> '{0[0](10)}'.format([None])
python: Objects/stringlib/string_format.h:379: FieldNameIterator_next:
Assertion `0' failed.
zsh: abort      ./python

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6089>
_______________________________________

From report at bugs.python.org  Fri May 22 18:54:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 May 2009 16:54:54 +0000
Subject: [issue6089] str.format raises SystemError
In-Reply-To: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>
Message-ID: <1243011294.63.0.605797769713.issue6089@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6089>
_______________________________________

From report at bugs.python.org  Fri May 22 18:55:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 May 2009 16:55:35 +0000
Subject: [issue6089] str.format raises SystemError
In-Reply-To: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>
Message-ID: <1243011335.51.0.443680627891.issue6089@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6089>
_______________________________________

From report at bugs.python.org  Fri May 22 19:00:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 May 2009 17:00:25 +0000
Subject: [issue6078] freeze.py doesn't work
In-Reply-To: <1242916100.37.0.236967212575.issue6078@psf.upfronthosting.co.za>
Message-ID: <1243011625.48.0.544948386548.issue6078@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r72833.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6078>
_______________________________________

From report at bugs.python.org  Fri May 22 19:09:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 May 2009 17:09:02 +0000
Subject: [issue6083] Reference counting bug in setrlimit
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1243012142.16.0.437325598823.issue6083@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That is a good point.  IMHO we'll be fine with a warning in the docs,
and fixing our own two instances.  Martin, what do you think?

----------
assignee:  -> loewis
nosy: +georg.brandl, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Fri May 22 19:30:03 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 22 May 2009 17:30:03 +0000
Subject: [issue6089] str.format raises SystemError
In-Reply-To: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>
Message-ID: <1243013403.39.0.843525778437.issue6089@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Any character after a ']' other than '.' or '[' triggers this bug:

>>> '{0[0]x}'.format([None])
Assertion failed: (0), function FieldNameIterator_next, file
Objects/stringlib/string_format.h, line 379.

I'll fix it this weekend.

----------
assignee:  -> eric.smith
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6089>
_______________________________________

From report at bugs.python.org  Fri May 22 19:45:35 2009
From: report at bugs.python.org (Robert Cronk)
Date: Fri, 22 May 2009 17:45:35 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1243014335.81.0.514826846564.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I have had this problem with 2.6.1 on windows from multiple _threads_ 
instead of multiple processes.  Is that not supported either?  If not, 
what is the workaround for logging from multiple threads?  Shouldn't it 
be easy to use a semaphore within the logging code to make it thread 
safe at least?  I have had this problem on multiple PC's with multiple 
versions of python, and multiple versions of windows.

----------
nosy: +rcronk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Fri May 22 19:56:32 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 22 May 2009 17:56:32 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1243014992.33.0.0449023282325.issue6081@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri May 22 21:45:11 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 22 May 2009 19:45:11 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1243021511.31.0.869948382117.issue6071@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I would certainly like to, but unfortunately at present I am unable to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Fri May 22 21:54:03 2009
From: report at bugs.python.org (Joe Amenta)
Date: Fri, 22 May 2009 19:54:03 +0000
Subject: [issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243022043.84.0.0340471890976.issue6070@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

Python writes compiled files with the same file permissions as the
source module.  In your specific example:

$ python2.6 -c 'import module'

This will produce module.pyc with the same attributes as module.py

While I am not familiar with modifying C stat structs, I can say that in
trunk/Python/import.c, somewhere after line 977 but before line 1014,
the stat struct "st" must be examined for S_IXUSR, S_IXGRP, and S_IXOTH
and have those bits removed in order to never produce a compiled module
with "x" in the stat.  I would assign low priority to this issue, as it
has little impact on the behavior of Python, even though it might cause
unintended consequences to a user trying to execute the bytecode, if the
user interprets the "x" to mean that it is executable by the system.

----------
nosy: +joe.amenta

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri May 22 21:56:18 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 22 May 2009 19:56:18 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1243022178.82.0.882505016243.issue6071@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Perhaps Gregory has some idea about how this can most easily be
resolved, since I think he did the work on #3745 which introduced this
change in behavior.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Fri May 22 22:13:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 May 2009 20:13:26 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1243023206.66.0.195407395514.issue5756@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think it matters which version of 2to3 is used. It has a same
function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

From report at bugs.python.org  Fri May 22 22:32:12 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Fri, 22 May 2009 20:32:12 +0000
Subject: [issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243024332.15.0.217368165414.issue6070@psf.upfronthosting.co.za>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

I will try to look at import.c, though I must say I am a bad C
programmer. I have switched to Python after ten years of Pascal.

Low priority is ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri May 22 23:17:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 22 May 2009 21:17:54 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1243027074.31.0.67646579856.issue6071@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

to confirm, this is only a problem in 2.7 trunk right?

if so, i won't rush a fix.

but yes fallback code for legacy types or adding buffer api support to 
array would work.

----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat May 23 00:20:42 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 22 May 2009 22:20:42 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1243030842.07.0.792799590038.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This exact problem? Single process, multiple threads, one single handler
for a given file? Can you post an example which demonstrates your issue?

Multiple threads *are* supported by the logging package, as mentioned in
the documentation. If you can post a an example here, I'll take a look
at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Sat May 23 00:52:19 2009
From: report at bugs.python.org (Robert Cronk)
Date: Fri, 22 May 2009 22:52:19 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1243032739.56.0.489216492459.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I will go through the code and make sure I am not mistaken, but I do 
believe I have a single process, multiple threads, and only one handler 
for this file and I'm getting the same types of error messages shown on 
this page.  I'm probably doing something wrong.  I'll post what I find 
soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

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: [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 04:53:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 02:53:36 +0000
Subject: [issue4066] smtplib SMTP_SSL._get_socket doesn't return a value
In-Reply-To: <1223389575.89.0.292427308742.issue4066@psf.upfronthosting.co.za>
Message-ID: <1243047216.13.0.59752308883.issue4066@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied to trunk in r72835, with some test fixes after (to skip the test
if SSL isn't installed).  Applied to py3k in r72836, ditto on fixes.  I
also backported the fix and test to 26-maint and 30-maint.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4066>
_______________________________________

From report at bugs.python.org  Sat May 23 05:21:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 03:21:16 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1243048876.84.0.198065277843.issue5761@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Antoine, by "reused for f's repr" do you mean adding 'name=xxxx' into
the existing repr (probably before the encoding)?

Benjamin, by "bytes" do you mean BytesIO objects?  Would it be
acceptible to give them a 'name' attribute set to 'None'?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

From report at bugs.python.org  Sat May 23 06:57:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 04:57:10 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1243048876.84.0.198065277843.issue5761@psf.upfronthosting.co.za>
Message-ID: <1243054733.5233.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, by "reused for f's repr" do you mean adding 'name=xxxx' into
> the existing repr (probably before the encoding)?

Exactly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

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: [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 09:33:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 May 2009 07:33:38 +0000
Subject: [issue5079] time.ctime docs refer to "time tuple" for default
In-Reply-To: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>
Message-ID: <1243064018.77.0.576908004701.issue5079@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

None will be made.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5079>
_______________________________________

From report at bugs.python.org  Sat May 23 09:41:01 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 May 2009 07:41:01 +0000
Subject: [issue5797] there is en exception om Create User page
In-Reply-To: <1240200084.56.0.449706089015.issue5797@psf.upfronthosting.co.za>
Message-ID: <1243064461.5.0.42489452504.issue5797@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5797>
_______________________________________

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: [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 14:08:44 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=F6wis?=)
Date: Sat, 23 May 2009 12:08:44 +0000
Subject: [issue1064] Test issue
In-Reply-To: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za>
Message-ID: <1243080524.56.0.128563954404.issue1064@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

And yet more email

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1064>
_______________________________________

From report at bugs.python.org  Sat May 23 14:19:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 May 2009 12:19:48 +0000
Subject: [issue1064] Test issue
In-Reply-To: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za>
Message-ID: <1243081188.2.0.79661122402.issue1064@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Another one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1064>
_______________________________________

From report at bugs.python.org  Sat May 23 14:39:15 2009
From: report at bugs.python.org (mkv)
Date: Sat, 23 May 2009 12:39:15 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1243082355.36.0.760020144603.issue6054@psf.upfronthosting.co.za>


mkv <mvirkkil at cc.hut.fi> added the comment:

Great, thanks for the speedy work :) 

Now if only issue4750 would get fixed for 2.7 as well ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From report at bugs.python.org  Sat May 23 14:58:50 2009
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=)
Date: Sat, 23 May 2009 12:58:50 +0000
Subject: [issue960325] "--require <feature>" option for configure/make (fail
	if building not possible)
Message-ID: <1243083530.32.0.832869775805.issue960325@psf.upfronthosting.co.za>


Bj?rn Lindqvist <bjourne at gmail.com> added the comment:

I'm not Hallvard but I'd also appreciate this feature. I think it is
quite important to have for automated build systems; Python seem to
build correctly but then down the line some other package fails because
the bz2 module is not available. 

IMHO it is wrong that you _can_ build python without libbz2 (for
example) because what you get is a broken standard library. It is not
mentioned anywhere in the documentation that bz2 is an optional module.
I think terminating the build at the configure step if libbz2 is not
found would be correct.

Otherwise maybe the standard --with configure options could be used for
this. E.g. ./configure --with-bz2 --with-ssl etc.

----------
nosy: +bjourne

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue960325>
_______________________________________

From report at bugs.python.org  Sat May 23 16:15:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 14:15:00 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1243088100.9.0.978075186747.issue4470@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

With the closure of 4066 all the tests in the test patch pass, so I'm
lowering the piority of this ticket.

I haven't reviewed the other patches, but the tests in the test patch
appear to be doing tests in the setup method, which doesn't seem like a
good idea.

----------
nosy: +r.david.murray
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Sat May 23 16:22:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 14:22:34 +0000
Subject: [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1243088554.79.0.26930130804.issue4385@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless I'm missing something it looks like this can be closed as fixed.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________

From report at bugs.python.org  Sat May 23 16:24:18 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 14:24:18 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243088658.83.0.00169101690761.issue5259@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file13774/test-smtplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Sat May 23 16:34:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 14:34:08 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243089248.43.0.41375189538.issue5259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

5304 and 3921 are fixed.  Is there still an issue here?  If so, I think
we need a test case we can add to the test suite.  It can be a patch
against the new test_smtpnet.py test.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Sat May 23 16:39:01 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 23 May 2009 14:39:01 +0000
Subject: [issue6089] str.format raises SystemError
In-Reply-To: <1243009481.36.0.103262256104.issue6089@psf.upfronthosting.co.za>
Message-ID: <1243089541.84.0.0921544087505.issue6089@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Fixed in:
trunk: r72848
release26-maint: r72849
py3k: r72850
release30-main: r72851

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6089>
_______________________________________

From report at bugs.python.org  Sat May 23 16:47:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 14:47:58 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243090078.43.0.359494649451.issue5259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like I accidentally deleted the file I was asking for.  Not sure
how that happened, but I'm reattaching it.

----------
Added file: http://bugs.python.org/file14043/test-smtplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Sat May 23 18:15:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 May 2009 16:15:03 +0000
Subject: [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: <1243095303.55.0.856017554769.issue6047@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Removed fullinstall in r72857.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6047>
_______________________________________

From report at bugs.python.org  Sat May 23 18:22:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 16:22:04 +0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1243095724.85.0.192669496706.issue1983@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, the patch was committed in r72852, r72853, r72854.
I then realized a couple of functions had been looked over (including
getpid() and getppid()), and committed a complement in r72855, r72856
and r72858.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
_______________________________________

From report at bugs.python.org  Sat May 23 18:35:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 16:35:58 +0000
Subject: [issue3877] test_fileio fails on OpenBSD 4.4
In-Reply-To: <1221542542.67.0.83676817672.issue3877@psf.upfronthosting.co.za>
Message-ID: <1243096558.45.0.242019738778.issue3877@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a more generic fix to test_fileio. Normally it should be
ok, if there's any problem please reopen the bug.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3877>
_______________________________________

From report at bugs.python.org  Sat May 23 18:55:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 May 2009 16:55:29 +0000
Subject: [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1243097729.69.0.0704533115607.issue4385@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________

From report at bugs.python.org  Sat May 23 19:10:39 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 May 2009 17:10:39 +0000
Subject: [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: <1243098639.78.0.47858532224.issue6050@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It would be nice to have a test with the patch.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6050>
_______________________________________

From report at bugs.python.org  Sat May 23 19:13:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 May 2009 17:13:53 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1243098833.12.0.272790746444.issue5756@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r72866 installs 2to3 over old installations. That should do the trick.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

From report at bugs.python.org  Sat May 23 19:58:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 17:58:37 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1243101517.35.0.362629887758.issue5761@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file14044/issue5761.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

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: [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  Sat May 23 20:21:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 May 2009 18:21:08 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243102868.14.0.226204112216.issue5259@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
stage: test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Sat May 23 20:48:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 18:48:57 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1243104537.74.0.036373385651.issue5761@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch following Benjamin's comments.

----------
Added file: http://bugs.python.org/file14046/issue5761-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

From report at bugs.python.org  Sat May 23 20:51:25 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 May 2009 18:51:25 +0000
Subject: [issue6094] Python fails to build with Subversion 1.7
In-Reply-To: <1243102798.53.0.847495660834.issue6094@psf.upfronthosting.co.za>
Message-ID: <1243104685.99.0.1062663651.issue6094@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching improved patch.

----------
Added file: http://bugs.python.org/file14047/python-2.6.2-svnversion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6094>
_______________________________________

From report at bugs.python.org  Sat May 23 20:54:08 2009
From: report at bugs.python.org (soundmurderer)
Date: Sat, 23 May 2009 18:54:08 +0000
Subject: [issue6060] PYTHONHOME should be more flexible (and controllable by
	--libdir)
In-Reply-To: <1242712344.32.0.862299052402.issue6060@psf.upfronthosting.co.za>
Message-ID: <1243104848.93.0.950118178235.issue6060@psf.upfronthosting.co.za>


soundmurderer <soundmurderer at gmail.com> added the comment:

OK, I'm convinced.  Changing PYTHONHOME is bad.  But I am all in favor
R. David Murray's solution of extending to include something like
PYTHONHOMELIB.

Martin v. L?wis: What I want is simply to be able to use --libdir to
tell ./configure where to put standard Python libs, and I want my Python
installation to recognize this lib location without having to hack
PYTHONPATH or PYTHONHOME or anything else.

This would make the behavior of --libdir exactly what people generally
expect from using configure scripts supplied by many other projects.  As
of now, setting --libdir doesn't even do anything, silently!  But even
fixing --libdir per patch in http://bugs.python.org/issue858809 still
doesn't work because the lib path has a hardcoded component.

I just think that a sys admin, when he/she sees a configure script,
should be able to tell it what to do via flags, run it, and expect it to
Do The Right Thing, without worrying about the Python-specific
workarounds to make libs and bins go to the desired place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6060>
_______________________________________

From report at bugs.python.org  Sat May 23 21:04:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 19:04:23 +0000
Subject: [issue5761] add file name to py3k IO objects repr()
In-Reply-To: <1239792347.2.0.639213233478.issue5761@psf.upfronthosting.co.za>
Message-ID: <1243105463.16.0.0868740025156.issue5761@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r72870.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5761>
_______________________________________

From report at bugs.python.org  Sat May 23 21:25:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 May 2009 19:25:12 +0000
Subject: [issue6094] Python fails to build with Subversion 1.7
In-Reply-To: <1243102798.53.0.847495660834.issue6094@psf.upfronthosting.co.za>
Message-ID: <1243106712.85.0.998688965638.issue6094@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r72871.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6094>
_______________________________________

From report at bugs.python.org  Sat May 23 22:17:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 May 2009 20:17:30 +0000
Subject: [issue6060] PYTHONHOME should be more flexible (and controllable
	by	--libdir)
In-Reply-To: <1243104848.93.0.950118178235.issue6060@psf.upfronthosting.co.za>
Message-ID: <4A1859D5.6060407@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin v. L?wis: What I want is simply to be able to use --libdir to
> tell ./configure where to put standard Python libs, and I want my Python
> installation to recognize this lib location without having to hack
> PYTHONPATH or PYTHONHOME or anything else.

Ok. Then I shall close this report as "won't fix", because
a) we cannot change the semantics of the environment variables easily,
   and
b) changing environment variables doesn't solve your original problem.

----------
title: PYTHONHOME should be more flexible (and controllable by --libdir) -> PYTHONHOME should be more flexible (and controllable by	--libdir)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6060>
_______________________________________

From report at bugs.python.org  Sat May 23 22:18:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 May 2009 20:18:02 +0000
Subject: [issue6060] PYTHONHOME should be more flexible (and controllable
	by	--libdir)
In-Reply-To: <1242712344.32.0.862299052402.issue6060@psf.upfronthosting.co.za>
Message-ID: <1243109882.12.0.40714775356.issue6060@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6060>
_______________________________________

From report at bugs.python.org  Sun May 24 00:34:35 2009
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Luis_C=C3=A1ceres?=)
Date: Sat, 23 May 2009 22:34:35 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243118075.87.0.403207318838.issue5259@psf.upfronthosting.co.za>


Jos? Luis C?ceres <jlc at telefonica.net> added the comment:

There is a similar problem that I found with encode_cram_md5 in 
smtplib.py, SMTP.login() method. I used the solution proposed by miwa, 
both for PLAIN and CRAM MD5 authentication. Additionally, for the last 
one, I had to introduce a second correction and byte encode the 
password string when passing it to hmac.HMAC.  

I do not know if I did things correctly, but just in case it can help  
here is the complete patch that I used and worked well with the two 
AUTH methods. I keep the original and modified lines for clarity.

def encode_cram_md5(challenge, user, password):
            challenge = base64.decodestring(challenge)
            #response = user + " " + hmac.HMAC(password,    
challenge).hexdigest()
            response = user + " " + hmac.HMAC(password.encode(), 
challenge).hexdigest()
            #return encode_base64(response)
            return encode_base64((response).encode('ascii'), eol='')
            
        def encode_plain(user, password):
            #return encode_base64("\0%s\0%s" % (user, password))
            return encode_base64(("\0%s\0%s" % (user, password)).encode
('ascii'), eol='')

----------
nosy: +j.l.caceres

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Sun May 24 01:09:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 May 2009 23:09:39 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243120179.37.0.132701622615.issue1943@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against py3k. On a 64-bit system, each unicode object
takes 14 bytes less than without the patch (using sys.getsizeof()).
Two to four more bytes could be gained by folding the `state` member in
the two lower bits of `defenc`, but I'm not sure it's worth the trouble.

----------
assignee: lemburg -> 
stage: test needed -> patch review
Added file: http://bugs.python.org/file14048/unialloc5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sun May 24 01:24:07 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 23 May 2009 23:24:07 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1243121047.86.0.874422904092.issue6042@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Committed to trunk in r72879. I'll wait to merge it to 3.x until 3.1 has
been released, since we're approaching the release candidate there.

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Sun May 24 01:24:20 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 23 May 2009 23:24:20 +0000
Subject: [issue6042] Document and slightly simplify lnotab tracing
In-Reply-To: <1242505022.27.0.997047692556.issue6042@psf.upfronthosting.co.za>
Message-ID: <1243121060.65.0.881220263535.issue6042@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin <jyasskin at gmail.com>:


----------
assignee:  -> jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6042>
_______________________________________

From report at bugs.python.org  Sun May 24 01:54:47 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 May 2009 23:54:47 +0000
Subject: [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 13:09:16 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 24 May 2009 11:09:16 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1243163355.93.0.667969693259.issue1424152@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Fixed for Py2x in the revision 72880. Tested it on a Squid Proxy setup
and found it working fine. Should this be backported?

For Py3k, the Request class has undergone changes since the patch was
developed, I am modifying the patch for Py3k to accommodate those changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sun May 24 13:40:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 11:40:40 +0000
Subject: [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: <1243165240.31.0.917108199196.issue6074@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Sun May 24 13:44:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 11:44:07 +0000
Subject: [issue6073] threading.Timer and gtk.main are not compatible
In-Reply-To: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>
Message-ID: <1243165447.86.0.907887150846.issue6073@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is probably a problem with the gtk/gobject Python binding.
By the way, you're supposed to call `gobject.threads_init()` if you use
threads with Python and gobject/gtk.
Besides, gtk certainly has its own timing facilities, while
threading.Timer is rather crude.

----------
nosy: +pitrou
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6073>
_______________________________________

From report at bugs.python.org  Sun May 24 13:46:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 11:46:08 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1243165568.89.0.0848456975976.issue1309352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Gonna apply if nobody opposes :)

----------
assignee: nnorwitz -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Sun May 24 16:10:25 2009
From: report at bugs.python.org (Marco)
Date: Sun, 24 May 2009 14:10:25 +0000
Subject: [issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243174225.52.0.251965056344.issue6070@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

I attach a patch to correct this little bug.

Bye ;)

----------
nosy: +markon
Added file: http://bugs.python.org/file14049/import_patch.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Sun May 24 16:52:01 2009
From: report at bugs.python.org (Eric)
Date: Sun, 24 May 2009 14:52:01 +0000
Subject: [issue6073] threading.Timer and gtk.main are not compatible
In-Reply-To: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>
Message-ID: <1243176721.23.0.577785840826.issue6073@psf.upfronthosting.co.za>


Eric <eric at ericaro.net> added the comment:

OK, this is a workaround. 

adding this line 
gtk.gdk.threads_init()

makes the job. And that's ok for me.

nevertheless, I still got the feeling that's this is a flaw in the Timer
implementation: it's behaviour is changed by some external (gtk) code.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6073>
_______________________________________

From report at bugs.python.org  Sun May 24 16:53:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 May 2009 14:53:23 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243176803.51.0.179684372537.issue5259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed the simple auth tests and fix in r72868 in py3k and r72877 in
3.0.  Also added the test to trunk in r72878 to keep the test source in
sync, and to 26maint similarly in r72886.

Now we need tests for the other auth cases.

----------
stage: commit review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Sun May 24 16:57:39 2009
From: report at bugs.python.org (Marco)
Date: Sun, 24 May 2009 14:57:39 +0000
Subject: [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: <1243177059.2.0.912389527418.issue6074@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

It seems Python is using a default mask to compile modules.
If you open a file b.py as "r", and you import it from a.py, you can see
that b.pyc is:
-rwxr-xr-x 1 marco marco    9 24 mag 16:17 a.py
-r--r--r-- 1 marco marco   10 24 mag 16:17 b.py
-rw-r--r-- 1 marco marco  122 24 mag 16:46 b.pyc

If you try to run a.py:
-rwxr-xr-x 1 marco marco    9 24 mag 16:17 a.py
-r-xr-xr-x 1 marco marco   10 24 mag 16:17 b.py

you'll get:
-rw-r--r-- 1 marco marco  122 24 mag 16:49 b.pyc

as you can see, there is a default "mode" to create compiled modules...

----------
nosy: +markon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Sun May 24 17:47:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 15:47:54 +0000
Subject: [issue1309352] Make fcntl work properly on AMD64
Message-ID: <1243180074.72.0.23278753185.issue1309352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r72887, r72888, r72889. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309352>
_______________________________________

From report at bugs.python.org  Sun May 24 18:06:44 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 24 May 2009 16:06:44 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <4A1703CE.7010206@v.loewis.de>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B67502A1A9C7@hornigold.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks again Martin for the guidance.  It proved quite helpful in completing 
this patch.

This latest version (3) compiles and has been tested under Windows Vista and 
Windows XP and behaves as expected (with a NotImplemented error under XP).

I did find that I had to tweak the behavior of stat.S_ISLNK because my 
implementation of the st_mode bits for a symlink has different values than 
that of a posix call.  I don't fully understand the implications of my 
implementation.

An alternate implementation would be to have set_symlink_stat[AW] reset all of 
the st_mode flags except for 0o120000, to be consistent with what is returned 
by a posix stat call.  This approach doesn't seem quite right either.  I would 
appreciate a comment on this by someone more familiar with this type of 
problem.

Other than that issue, what else needs to be addressed to get this patch 
integrated into the 3.1 or 3.1.1 release?

----------
title: Add os.link() and os.symlink() and	os.path.islink() support for Windows -> Add os.link() and os.symlink() and os.path.islink()	support for Windows
Added file: http://bugs.python.org/file14050/windows symlink draft 3.patch
Added file: http://bugs.python.org/file14051/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________
-------------- next part --------------
Index: Lib/stat.py
===================================================================
--- Lib/stat.py	(revision 72889)
+++ Lib/stat.py	(working copy)
@@ -53,7 +53,7 @@
     return S_IFMT(mode) == S_IFIFO
 
 def S_ISLNK(mode):
-    return S_IFMT(mode) == S_IFLNK
+    return bool(S_IFMT(mode) & S_IFLNK)
 
 def S_ISSOCK(mode):
     return S_IFMT(mode) == S_IFSOCK
Index: Lib/ntpath.py
===================================================================
--- Lib/ntpath.py	(revision 72889)
+++ Lib/ntpath.py	(working copy)
@@ -306,13 +306,19 @@
     return split(p)[0]
 
 # Is a path a symbolic link?
-# This will always return false on systems where posix.lstat doesn't exist.
+# This will always return false on systems where os.lstat doesn't exist.
 
 def islink(path):
-    """Test for symbolic link.
-    On WindowsNT/95 and OS/2 always returns false
     """
-    return False
+    Test whether a path is a symbolic link.
+    This will always return false for Windows prior to 6.0
+    and for OS/2.
+    """
+    try:
+        st = os.lstat(path)
+    except (os.error, AttributeError):
+        return False
+    return stat.S_ISLNK(st.st_mode)
 
 # alias exists to lexists
 lexists = exists
Index: Modules/posixmodule.c
===================================================================
--- Modules/posixmodule.c	(revision 72889)
+++ Modules/posixmodule.c	(working copy)
@@ -1005,6 +1005,45 @@
 	return 0;
 }
 
+void set_symlink_statA(
+	const char *path,
+	WIN32_FILE_ATTRIBUTE_DATA *info,
+	struct win32_stat *result)
+{
+	/* Get WIN32_FIND_DATA structure for the path to determine if
+	   it is a symlink */
+	WIN32_FIND_DATAA find_data;
+	HANDLE find_data_handle;
+	if(!(info->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) return;
+	find_data_handle = FindFirstFileA(path, &find_data);
+	if(find_data_handle != INVALID_HANDLE_VALUE)
+	{
+		if(find_data.dwReserved0 == IO_REPARSE_TAG_SYMLINK)
+			result->st_mode |= 0120000;
+		FindClose(find_data_handle);
+	}
+}
+
+void set_symlink_statW(
+	const wchar_t *path,
+	WIN32_FILE_ATTRIBUTE_DATA *info,
+	struct win32_stat *result)
+{
+	/* Get WIN32_FIND_DATA structure for the path to determine if
+	   it is a symlink */
+	WIN32_FIND_DATAW find_data;
+	HANDLE find_data_handle;
+	if(!(info->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) return;
+	find_data_handle = FindFirstFileW(path, &find_data);
+	if(find_data_handle != INVALID_HANDLE_VALUE)
+	{
+		if(find_data.dwReserved0 == IO_REPARSE_TAG_SYMLINK)
+			result->st_mode |= 0120000;
+		FindClose(find_data_handle);
+	}
+}
+
+
 /* Emulate GetFileAttributesEx[AW] on Windows 95 */
 static int checked = 0;
 static BOOL (CALLBACK *gfaxa)(LPCSTR, GET_FILEEX_INFO_LEVELS, LPVOID);
@@ -1143,6 +1182,9 @@
 	code = attribute_data_to_stat(&info, result);
 	if (code != 0)
 		return code;
+
+	set_symlink_statA(path, &info, result);
+
 	/* Set S_IFEXEC if it is an .exe, .bat, ... */
 	dot = strrchr(path, '.');
 	if (dot) {
@@ -1181,6 +1223,9 @@
 	code = attribute_data_to_stat(&info, result);
 	if (code < 0)
 		return code;
+
+	set_symlink_statW(path, &info, result);
+
 	/* Set IFEXEC if it is an .exe, .bat, ... */
 	dot = wcsrchr(path, '.');
 	if (dot) {
@@ -4736,7 +4781,79 @@
 }
 #endif /* HAVE_SYMLINK */
 
+#if !defined(HAVE_SYMLINK) && defined(MS_WINDOWS)
 
+/* Grab CreateSymbolicLinkW dynamically from kernel32 */
+static int has_CreateSymbolicLinkW = 0;
+static DWORD (CALLBACK *Py_CreateSymbolicLinkW)(LPWSTR, LPWSTR, DWORD);
+static int
+check_CreateSymbolicLinkW()
+{
+	HINSTANCE hKernel32;
+	/* only recheck */
+	if (has_CreateSymbolicLinkW)
+	    return has_CreateSymbolicLinkW;
+	hKernel32 = GetModuleHandle("KERNEL32");
+	*(FARPROC*)&Py_CreateSymbolicLinkW = GetProcAddress(hKernel32, "CreateSymbolicLinkW");
+	if (Py_CreateSymbolicLinkW)
+		has_CreateSymbolicLinkW = 1;
+	return has_CreateSymbolicLinkW;
+}
+
+PyDoc_STRVAR(win_symlink__doc__,
+"symlink(src, dest, target_is_directory=False)\n\n\
+Create a symbolic link pointo to src named dst.\n\n\
+target_is_directory is required if the target is to be interpreted as\n\n\
+a directory.\\\
+This function requires Windows 6.0 or greater, and raises a\n\n\
+NotImplementedError otherwise.");
+
+static PyObject *
+win_symlink(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+	static char *kwlist[] = {"src", "dest", "target_is_directory", NULL};
+	PyObject *src, *dest;
+	int target_is_directory = 0;
+	DWORD res;
+	
+	if (!check_CreateSymbolicLinkW())
+	{
+		/* raise NotImplementedError */
+		return PyErr_Format(PyExc_NotImplementedError,
+			"CreateSymbolicLinkW not found");
+	}
+	if (!PyArg_ParseTupleAndKeywords(args, kwargs, "OO|i:symlink",
+		kwlist, &src, &dest, &target_is_directory))
+		return NULL;
+	if (!convert_to_unicode(&src)) { return NULL; }
+	if (!convert_to_unicode(&dest)) {
+		Py_DECREF(src);
+		return NULL;
+	}
+	/* TODO: if dest is a directory, ensure target_is_directory==1
+	Something like:
+	target_is_directory ||= ntpath.isdir(dest);
+	
+	only ntpath doesn't exist in this context.
+	*/
+	Py_BEGIN_ALLOW_THREADS
+	res = Py_CreateSymbolicLinkW(
+		PyUnicode_AsUnicode(src),
+		PyUnicode_AsUnicode(dest),
+		target_is_directory);
+	Py_END_ALLOW_THREADS
+	Py_DECREF(src);
+	Py_DECREF(dest);
+	if (!res)
+	{
+		return win32_error_unicode("symlink", PyUnicode_AsUnicode(src));
+	}
+	
+	Py_INCREF(Py_None);
+	return Py_None;
+}
+#endif /* !defined(HAVE_SYMLINK) && defined(MS_WINDOWS) */
+
 #ifdef HAVE_TIMES
 #if defined(PYCC_VACPP) && defined(PYOS_OS2)
 static long
@@ -7100,6 +7217,9 @@
 #ifdef HAVE_SYMLINK
 	{"symlink",	posix_symlink, METH_VARARGS, posix_symlink__doc__},
 #endif /* HAVE_SYMLINK */
+#if !defined(HAVE_SYMLINK) && defined(MS_WINDOWS)
+	{"symlink", (PyCFunction)win_symlink, METH_VARARGS | METH_KEYWORDS, win_symlink__doc__},
+#endif /* !defined(HAVE_SYMLINK) && defined(MS_WINDOWS)
 #ifdef HAVE_SYSTEM
 	{"system",	posix_system, METH_VARARGS, posix_system__doc__},
 #endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6998 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090524/ec9c18fc/attachment.bin>

From report at bugs.python.org  Sun May 24 18:09:51 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 24 May 2009 16:09:51 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1243181391.79.0.317912096325.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file14051/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun May 24 18:09:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 16:09:54 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1243181394.53.0.305793945762.issue3585@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is there any reason in versioning Misc/python.pc, instead of versioning
it only on install?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sun May 24 18:32:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 16:32:34 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1243182754.04.0.359011857791.issue1518@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Sun May 24 18:43:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 16:43:40 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1243183420.79.0.0121152371676.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Current results:

test_modulefinder leaked [145, 145] references, sum=290
test_urllib leaked [10, 0] references, sum=10
test_urllib2 leaked [227, 227] references, sum=454

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Sun May 24 18:50:42 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 24 May 2009 16:50:42 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1243183842.78.0.357192494536.issue6001@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Updated patch with documentation and fixed command line usage message.

Unless there are objections I intend to check this in in the next few
days. It would be helpful if someone else could go over the
documentation and check for errors / typos etc.

I've already had feedback from a few folks. The only suggestions so far
have been:

* Instead of a discover method the functionality could be built into
TestLoader.loadTestsFromPath. This would be a substantial change and I
think it better belongs in a new method.
* discover could simply load all modules and discover TestCases instead
of needing a pattern to filter on. I think filtering is an important
feature (not least for performance and because importing arbitrary
modules is not safe). Loading all modules can be had by passing in a
pattern of '*'

The behavior as implemented is a subset of the test discovery provided
by frameworks like nose (which doesn't require all test modules to be
importable from the top level).

The load_tests protocol is an idea already in use by the Bzr test
framework and similar protocols are in use in other frameworks.

----------
Added file: http://bugs.python.org/file14052/test_discovery.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

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: [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 19:07:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 17:07:53 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243184873.17.0.0782962989643.issue6070@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
title: Pyhon 2.6 makes .pyc/.pyo bytecode files executable -> Python 2.6 makes .pyc/.pyo bytecode files executable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Sun May 24 19:24:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 17:24:46 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1243185886.25.0.998793513801.issue1578269@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch (v3) looks technically correct, with two minor issues: perhaps
one should release the handle to kernel32 (not sure whether other code
does it, or whether it matters), and I would inline the two new
functions into their single callers.

That aside, I sense a bigger issue of getting stat/lstat correct. In the
presence of symbolic links, stat(2) is supposed to look at the file that
is being linked to, whereas lstat is supposed to look at the link
itself. Currently, lstat and stat do the same thing on Windows, as the
assumption was that there are no symbolic links, anyway (in which case
lstat does indeed return the same as stat always). This assumption is no
longer correct - so the two functions need to be separated.

I don't know what the most efficient way is to do a real stat() on Vista
- ideally, the Get* APIs would take a flag to follow links. If that
doesn't work, we would need to resolve the link ourselves, and look at
the file being referenced. Possible errors (on POSIX) for stat then are
ENOENT (broken symlink), ELOOP (symlink loop), ENOTDIR (path component
in symlink value is not a directory), and EACCESS (path component in
symlink, or target file is not accessible). This is just FYI; we should
raise the appropriate Win32 errors (and hopefully, we don't have to do
it ourselves, anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun May 24 19:54:03 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 24 May 2009 17:54:03 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1243187643.69.0.185570494551.issue6001@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Georg Brandl has pointed out various minor issues in the docs (and
discover docstring) that I am correcting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

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: [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 20:07:28 2009
From: report at bugs.python.org (David Watson)
Date: Sun, 24 May 2009 18:07:28 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1243188448.13.0.610312388152.issue4859@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Patch to make pwd, spwd and grp decode their string fields using
the file system encoding and the "surrogateescape" error handler,
as per PEP 383.

----------
Added file: http://bugs.python.org/file14055/surrogateescape-fields.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Sun May 24 20:08:58 2009
From: report at bugs.python.org (David Watson)
Date: Sun, 24 May 2009 18:08:58 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1243188538.29.0.0276622276635.issue4859@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Patch to make get*nam() functions encode their arguments using
the file system encoding and "surrogateescape" error handler, so
that they correctly handle the user/group name fields returned by
each other.

----------
Added file: http://bugs.python.org/file14056/surrogateescape-args.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Sun May 24 20:12:43 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 24 May 2009 18:12:43 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1243188763.7.0.457865024142.issue1424152@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I added a versionadded: 2.7 note to the docs in r72890.

This change is not suitable for back porting as it arguably adds a new 
feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sun May 24 21:20:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 19:20:16 +0000
Subject: [issue6065] bdist_msi.py failed assert when including extension
	modules
In-Reply-To: <4A1329EC.3020307@timgolden.me.uk>
Message-ID: <1243192816.14.0.750374380062.issue6065@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r72891 and r72892.

Please use 4-space indents in the future.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6065>
_______________________________________

From report at bugs.python.org  Sun May 24 21:55:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 19:55:47 +0000
Subject: [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: <1243194947.28.0.432602045911.issue6050@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed with modifications (including a test) as
r72893, r72894, r72895, r72896.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6050>
_______________________________________

From report at bugs.python.org  Sun May 24 21:57:25 2009
From: report at bugs.python.org (Clinton Roy)
Date: Sun, 24 May 2009 19:57:25 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1243195045.71.0.47186907265.issue3585@psf.upfronthosting.co.za>


Clinton Roy <clinton.roy at gmail.com> added the comment:

Not that I can see, or remember. Revised patch attached. Tyop fixed as well.

Please note there seem to be some issues with svn head atm,
pyconfig.h.in and configure would seem to be out of whack with
configure.in, this patch does not include changes to those generated files.

----------
Added file: http://bugs.python.org/file14057/pkgconfig.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sun May 24 22:09:05 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 May 2009 20:09:05 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243195745.37.0.399444128972.issue6070@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Are these S_IX... constants available on every platform we support?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Sun May 24 22:39:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 20:39:53 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1243197593.65.0.532837295706.issue3585@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is committed in trunk (r72898) and py3k (r72899). Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sun May 24 22:40:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 20:40:00 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243197600.5.0.582432138581.issue6070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No, they are not supported on Visual Studio.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

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: [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: [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  Sun May 24 23:04:20 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 21:04:20 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1243199060.54.0.546994843923.issue6012@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So: any opinions what approach would be better? A new converter O$ or a
change to the existing O&, selected by return value from the conversion
function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Sun May 24 23:18:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 21:18:40 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1243199920.65.0.0262838239677.issue6012@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reusing O& looks better to me (we already have too many type specifiers). 
Why have you chosen 0x20000 for Py_CLEANUP_SUPPORTED? Are there other
possible values below that?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Sun May 24 23:31:01 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 24 May 2009 21:31:01 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243200661.87.0.828622277146.issue1943@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine, I think we have to make a decision here: I'm still -1 on
changing PyUnicodeObject to be a PyVarObject, but do like your
experiments with the free lists.

I also still believe that tuning the existing parameters in the Unicode
implementation and pymalloc would give a better performance gain than
what your patch achieves. 

Setting KEEPALIVE_SIZE_LIMIT to 32 would be a first start in that direction.

However, if you insist on changing the PyUnicodeObject structure, I'll
have to reject the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sun May 24 23:36:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 21:36:46 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243201006.74.0.525318343326.issue1943@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I already showed, the freelist experiments bring very little improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sun May 24 23:39:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 May 2009 21:39:42 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1243199920.65.0.0262838239677.issue6012@psf.upfronthosting.co.za>
Message-ID: <4A19BE9A.5060407@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Reusing O& looks better to me (we already have too many type specifiers). 
> Why have you chosen 0x20000 for Py_CLEANUP_SUPPORTED? Are there other
> possible values below that?

It's essentially random. I want it to be a power of two, in case we make
it a bit mask some day, and significantly different from 1. 0x20000 was
the smallest number that qualified :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Sun May 24 23:48:39 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 24 May 2009 21:48:39 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243201719.27.0.411005552161.issue1943@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ok, then closing the patch as rejected.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sun May 24 23:51:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 21:51:45 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243201905.4.0.698788372184.issue1943@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Marc-Andr?, please don't close the issue while you're the only one
opposing it, thanks.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

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: [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:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 May 2009 23:31:38 +0000
Subject: [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 01:52:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 May 2009 23:52:28 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243209148.52.0.196068499624.issue6101@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Performance numbers:

With patch:

$ ./python.exe -m timeit -s 'import thread; l = thread.allocate_lock()'
'with l: pass'
1000000 loops, best of 3: 1.99 usec per loop

Without:
100000 loops, best of 3: 2.15 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 01:59:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 May 2009 23:59:09 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243209549.38.0.699776358822.issue6101@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure I understand the point of PyInstance_Check() in
lookup_special().

You should bump the bytecode version in import.c.

By the way, there are some "with" tests in pybench (you can run them
using "-t With").

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 02:00:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 00:00:51 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243209549.38.0.699776358822.issue6101@psf.upfronthosting.co.za>
Message-ID: <1afaf6160905241700n74c1e1fcic4ce7fdac45e8d08@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/5/24 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> I'm not sure I understand the point of PyInstance_Check() in
> lookup_special().

_PyObject_LookupSpecial doesn't understand classic classes.

>
> You should bump the bytecode version in import.c.

Ok

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 02:01:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 May 2009 00:01:13 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243209673.32.0.228383766028.issue6101@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Endly, in compile.c, it seems the stack effect of SETUP_WITH should be
1, not 3 (only one value is pushed onto the stack).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 02:12:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 00:12:51 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243210371.34.0.93639739232.issue6101@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file14061/SETUP_WITH2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 03:23:07 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 25 May 2009 01:23:07 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1243214587.24.0.199660759748.issue6012@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> Reusing O& looks better to me

Me too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Mon May 25 03:47:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 01:47:28 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243216048.74.0.733637903073.issue6101@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file14062/SETUP_WITH3.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: [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 04:06:12 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 May 2009 02:06:12 +0000
Subject: [issue6094] Python fails to build with Subversion 1.7
In-Reply-To: <1243102798.53.0.847495660834.issue6094@psf.upfronthosting.co.za>
Message-ID: <1243217172.74.0.749029278253.issue6094@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
type:  -> compile error
versions:  -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6094>
_______________________________________

From report at bugs.python.org  Mon May 25 04:09:49 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 25 May 2009 02:09:49 +0000
Subject: [issue5794] pickle/cPickle of recursive tuples create pickles that
	cPickle can't load
In-Reply-To: <1240170780.68.0.204813353535.issue5794@psf.upfronthosting.co.za>
Message-ID: <1243217389.69.0.786685353184.issue5794@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Bug-fix patch attached. Alexandre, can you take a look? Feel free to
bounce it back if you don't have time.

I'll port to 2.6 and py3k once this is reviewed for trunk.

----------
keywords: +26backport, easy, patch
nosy: +alexandre.vassalotti
stage:  -> patch review
versions: +Python 2.7, Python 3.1 -Python 2.5
Added file: http://bugs.python.org/file14064/rec_tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5794>
_______________________________________

From report at bugs.python.org  Mon May 25 04:23:03 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 25 May 2009 02:23:03 +0000
Subject: [issue5866] cPickle defect with tuples and different from pickle
	output
In-Reply-To: <1240927564.03.0.455606352259.issue5866@psf.upfronthosting.co.za>
Message-ID: <1243218183.69.0.165567941708.issue5866@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5866>
_______________________________________

From report at bugs.python.org  Mon May 25 06:21:00 2009
From: report at bugs.python.org (Leeon)
Date: Mon, 25 May 2009 04:21:00 +0000
Subject: [issue6088] Python3.0.1.1 is not available when system locale is
	zh_TW.eucTW
In-Reply-To: <1243007545.21.0.68248439701.issue6088@psf.upfronthosting.co.za>
Message-ID: <1243225260.44.0.407754435508.issue6088@psf.upfronthosting.co.za>


Leeon <leeon.li at ca.com> added the comment:

Hello David,

Thanks for your quick response!
I just downloaded Python3.0.1 source code and compiled it on my Debian
5.0 Linux using following commands:
root at li-le01-d5:~# ./configure
root at li-le01-d5:~# make
root at li-le01-d5:~# make altinstall

Then I try Python in interactive mod and found the problem. On my
system, there is not any output and error message in python3.0 console
when I try to execute some statments. See following screen reaction:

root at li-le01-d5:~# python3.0
Python 3.0.1 (r301:69556, May 26 2009, 19:48:24)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> loacle.getlocale()
>>> help()
>>> exit()
>>> 

Then I try to execute a script file hello.py.
My script contains only one python statement: print('Hello World!')
On my system, there is not any output and error message also when I run
"python3.0 hello.py".
root at li-le01-d5:~# locale
LANG=zh_TW.EUC-TW
LC_CTYPE="zh_TW.EUC-TW"
LC_NUMERIC="zh_TW.EUC-TW"
LC_TIME="zh_TW.EUC-TW"
LC_COLLATE="zh_TW.EUC-TW"
LC_MONETARY="zh_TW.EUC-TW"
LC_MESSAGES="zh_TW.EUC-TW"
LC_PAPER="zh_TW.EUC-TW"
LC_NAME="zh_TW.EUC-TW"
LC_ADDRESS="zh_TW.EUC-TW"
LC_TELEPHONE="zh_TW.EUC-TW"
LC_MEASUREMENT="zh_TW.EUC-TW"
LC_IDENTIFICATION="zh_TW.EUC-TW"
LC_ALL=
root at li-le01-d5:~# /usr/local/bin/python3.0 hello.py
root at li-le01-d5:~#

Then I witch to zh_TW.utf8 and try it again.
root at li-le01-d5:~# LANG=zh_TW.utf8
root at li-le01-d5:~# locale
LANG=zh_TW.utf8
LC_CTYPE="zh_TW.utf8"
LC_NUMERIC="zh_TW.utf8"
LC_TIME="zh_TW.utf8"
LC_COLLATE="zh_TW.utf8"
LC_MONETARY="zh_TW.utf8"
LC_MESSAGES="zh_TW.utf8"
LC_PAPER="zh_TW.utf8"
LC_NAME="zh_TW.utf8"
LC_ADDRESS="zh_TW.utf8"
LC_TELEPHONE="zh_TW.utf8"
LC_MEASUREMENT="zh_TW.utf8"
LC_IDENTIFICATION="zh_TW.utf8"
LC_ALL=
root at li-le01-d5:~# /usr/local/bin/python3.0 hello.py
Hello world!
root at li-le01-d5:~#

This problem was also occurs when I try the same steps on HP-UX 11.11
and SUSE sles10.
Would you please kindly to tell me if I missed some steps when I compile
from source or some env variables from shell or some others.
The problem was strange and made me crazy.
I am very appreciated if you can tell me how to resolve it.

Thank you very much.
Leeon

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6088>
_______________________________________

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: [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 07:44:09 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 25 May 2009 05:44:09 +0000
Subject: [issue5670] Speed up pickling of dicts in cPickle
In-Reply-To: <1238698431.18.0.108052594941.issue5670@psf.upfronthosting.co.za>
Message-ID: <1243230249.72.0.733921424496.issue5670@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Fixed the len(d) == 1 size regression. Final performance of the patch
relative to trunk:

Using Unladen Swallow's perf.py -b pickle,pickle_dict on trunk:
pickle:
Min: 2.238 -> 1.895: 18.08% faster
Avg: 2.241 -> 1.898: 18.04% faster
Significant (t=282.066701, a=0.95)

pickle_dict:
Min: 2.163 -> 1.375: 57.36% faster
Avg: 2.168 -> 1.376: 57.50% faster
Significant (t=527.668441, a=0.95)


Performance for py3k:
pickle:
Min: 2.849 -> 2.790: 2.10% faster
Avg: 2.854 -> 2.796: 2.09% faster
Significant (t=27.624303, a=0.95)

pickle_dict:
Min: 2.121 -> 1.512: 40.27% faster
Avg: 2.128 -> 1.519: 40.13% faster
Significant (t=283.406572, a=0.95)


regrtest.py -uall test_xpickle passes all backwards-compatibility tests
for trunk, and all other tests run by regrtest.py on Linux pass.

Committed as r72909 (trunk), r72910 (py3k).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5670>
_______________________________________

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: [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 09:57:44 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 May 2009 07:57:44 +0000
Subject: [issue5756] idle pydoc et al removed from 3.1 without versioned
	replacements
In-Reply-To: <1239740660.49.0.649614984791.issue5756@psf.upfronthosting.co.za>
Message-ID: <1243238264.54.0.179331900455.issue5756@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Yep, r72866 does restore 2to3.  And r72857, which removes the fullinstall 
target, also fixes the problem of unversioned "python" and "python-config" 
files being created in bin.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5756>
_______________________________________

From report at bugs.python.org  Mon May 25 10:05:13 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 May 2009 08:05:13 +0000
Subject: [issue5272] OS X installer: fix makefile target changed for 3.x
In-Reply-To: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
Message-ID: <1243238713.91.0.399766460661.issue5272@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Issues update:

1. Benjamin fixed this in r72857.

2. Also fixed in r72857.

3. Fixed in r72866.

4. open - all that is needed is to add a NEWS item about smtpd.py no 
longer being installed as script

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________

From report at bugs.python.org  Mon May 25 10:17:56 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 May 2009 08:17:56 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243239476.41.0.694089874892.issue1943@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine, I have explained the reasons for rejecting the patch. In short,
it violates a design principle behind the Unicode implementation.

If you want to change such a basic aspect of the Unicode implementation,
then write a PEP which demonstrates the usefulness on a larger set of
more general tests and comes up with significant results (10% speedup in
some micro benchmarks is not significant; memory tests need to be run
without pymalloc and require extra care to work around OS malloc
optimization strategies).

Like I said: The current design of the Unicode object implementation
would benefit more from advances in pymalloc tuning, not from making it
next to impossible to extend the Unicode objects to e.g. 

 * reuse existing memory blocks for allocation, 
 * pointing straight into memory mapped files, 
 * providing highly efficient ways to tokenize Unicode data,
 * sharing of data between Unicode objects,
 etc.

The reason I chose this design was to make the above easily
implementable and it was a conscious decision to use a PyObject
rather than a PyVarObject, like the string object, since I knew 
that the Unicode object was eventually going to replace the string
object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon May 25 10:32:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 May 2009 08:32:22 +0000
Subject: [issue5653] OS X Installer: by default install versioned-only links
	in /usr/local/bin for 3.x
In-Reply-To: <1238604776.11.0.0788260895322.issue5653@psf.upfronthosting.co.za>
Message-ID: <1243240342.3.0.606989281273.issue5653@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the recent py3k changes to ensure that the bin directory only has 
versioned file names (and 2to3), the submitted patch can be simplified as 
the file name check is no longer needed.  Re-enabling the Unix Command 
Line Tools package by default is still appropriate, particularly now that 
there are no conflicts in /usr/local/bin between py2 and py3 file names 
(other than 2to3 which is OK).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5653>
_______________________________________

From report at bugs.python.org  Mon May 25 10:45:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 May 2009 08:45:45 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243241145.99.0.0906306322763.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Looking at the comments, it seems that the performance gain comes from
the removal of the double allocation which is needed by the current design.

Was the following implementation considered:
- keep the current PyUnicodeObject structure
- for small strings, allocate one chunk of memory:
sizeof(PyUnicodeObject)+2*length. Then set self->str=(Py_UNICODE*)(self+1);
- for large strings, self->str may be allocated separately.
- unicode_dealloc() must be careful and not free self->str if it is
contiguous to the object (it's probably a good idea to reuse the
self->state field for this purpose).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon May 25 11:21:05 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 May 2009 09:21:05 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243241145.99.0.0906306322763.issue1943@psf.upfronthosting.co.za>
Message-ID: <4A1A62FD.7030701@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Looking at the comments, it seems that the performance gain comes from
> the removal of the double allocation which is needed by the current design.
> 
> Was the following implementation considered:
> - keep the current PyUnicodeObject structure
> - for small strings, allocate one chunk of memory:
> sizeof(PyUnicodeObject)+2*length. Then set self->str=(Py_UNICODE*)(self+1);
> - for large strings, self->str may be allocated separately.
> - unicode_dealloc() must be careful and not free self->str if it is
> contiguous to the object (it's probably a good idea to reuse the
> self->state field for this purpose).

AFAIK, this was not yet been investigated.

Note that in real life applications, you hardly ever have to
call malloc on small strings - these are managed by pymalloc as
pieces of larger chunks and allocation/deallocation is generally
fast. You have the same situation for PyUnicodeObject itself
(which, as noted earlier, could be optimized in pymalloc even further,
since the size of PyUnicodeObject is fixed).

The OS malloc() is only called for longer strings and then only
for the string buffer itself - the PyUnicodeObject is again completly
managed by pymalloc, even in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

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: [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 11:24:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 May 2009 09:24:25 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243239476.41.0.694089874892.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243243585.5584.37.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Marc-Andr?, the problem is that all your arguments are fallacious at
best. Let me see:

> Like I said: The current design of the Unicode object implementation
> would benefit more from advances in pymalloc tuning, not from making it
> next to impossible to extend the Unicode objects to e.g. [...]

Saying that is like saying "we shouldn't try to improve ceval.c because
it makes it harder to write a JIT". You are dismissing concrete actual
improvements in favour of pie-in-the-sky improvements that nobody has
seemed to try (you're welcome to prove me wrong) in 10 years of
existence of the unicode type.

Besides, if someone wants to experiment with such improvements, it is
not difficult to switch back to the old representation (my patch is very
short if you discard the mechanic replacement of "self->length" with
"PyUnicode_GET_SIZE(self)", which doesn't have to be undone to switch
representations). So, I fail to see the relevance of that argument.

> Antoine, I have explained the reasons for rejecting the patch. In short,
> it violates a design principle behind the Unicode implementation.

You seem to be the only one thinking this while, AFAIK, you haven't been
the only one to work on that datatype.

> (10% speedup in
> some micro benchmarks is not significant; memory tests need to be run
> without pymalloc and require extra care to work around OS malloc
> optimization strategies).

Actually, running performance or resource consumption tests without
pymalloc is pointless since it makes the test completely artificial and
unrelated to real-world conditions (who runs Python without pymalloc in
real-world conditions?).

>  * reuse existing memory blocks for allocation, 
>  * pointing straight into memory mapped files, 
>  * providing highly efficient ways to tokenize Unicode data,
>  * sharing of data between Unicode objects,
>  etc.

By the way, I haven't seen your patches or experiments for those. Giving
guidance is nice, but proofs of concept, at the minimum, are more
convincing. None of the suggestions above strike me as very /easy/
(actually, they are at least an order of magnitude harder than the
present patch), or even guaranteed to give any tangible benefits.

To be clear, I don't think this proposal is more important than any
other one giving similar results (provided these exist). But your
arguments are never factual and, what's more, while I already did the
same replies as I did here in other messages, you never bothered to be
more factual. I would accept your refusal if your arguments had some
semblance of concrete support for them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon May 25 11:32:05 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 May 2009 09:32:05 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243243925.53.0.354867952078.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> The OS malloc() is only called...
I know this. But pymalloc has its own overhead, and cache locality will
certainly be better if string data is close to the string length.

The goal is to improve the current usage of strings, and not rely on
hypothetical enhancements to the generic pymalloc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon May 25 11:35:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 May 2009 09:35:40 +0000
Subject: [issue5670] Speed up pickling of dicts in cPickle
In-Reply-To: <1243230249.72.0.733921424496.issue5670@psf.upfronthosting.co.za>
Message-ID: <1243244263.5584.38.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks!

> Committed as r72909 (trunk), r72910 (py3k).
> 
> ----------
> resolution: accepted -> fixed
> status: open -> closed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5670>
_______________________________________

From report at bugs.python.org  Mon May 25 11:37:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 May 2009 09:37:50 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243244270.56.0.567595174797.issue6101@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

SETUP_WITH3.patch looks good to me.

----------
resolution:  -> accepted
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 12:34:04 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 25 May 2009 10:34:04 +0000
Subject: [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: <1243247644.13.0.541985363148.issue6099@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I attach another patch, keepalive.patch, which includes the fixes from http://bugs.python.org/issue6096 and including a test for the keepalive 
mecahinsm in the test suite.

Updated http://codereview.appspot.com/63144

----------
Added file: http://bugs.python.org/file14067/keepalive.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6099>
_______________________________________

From report at bugs.python.org  Mon May 25 14:47:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 12:47:54 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243255674.96.0.666803805771.issue6105@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Mon May 25 15:14:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 13:14:11 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1243257251.36.0.204424347607.issue6101@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r72912.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Mon May 25 15:48:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 13:48:46 +0000
Subject: [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: <1243259326.19.0.0380071438921.issue6104@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r72913.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6104>
_______________________________________

From report at bugs.python.org  Mon May 25 16:01:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 May 2009 14:01:14 +0000
Subject: [issue4547] Long jumps with frame_setlineno
In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za>
Message-ID: <1243260074.13.0.434526883063.issue4547@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4547>
_______________________________________

From report at bugs.python.org  Mon May 25 18:13:06 2009
From: report at bugs.python.org (Pal Subbiah)
Date: Mon, 25 May 2009 16:13:06 +0000
Subject: [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  Mon May 25 19:11:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 May 2009 17:11:52 +0000
Subject: [issue1707753] get status output fix for Win32
Message-ID: <1243271512.19.0.79562581272.issue1707753@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The 'commands' module is deprecated, and has been removed in Python 3.0:
http://docs.python.org/dev/library/commands.html

The recommended (and portable) method is to use subprocess:
    p = subprocess.Popen(command, stdout=PIPE, stderr=STDOUT, shell=True)
    output = p.communicate()[0]

I suggest closing this issue.

----------
nosy: +amaury.forgeotdarc
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1707753>
_______________________________________

From report at bugs.python.org  Mon May 25 19:12:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 May 2009 17:12:47 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1243271567.84.0.00215821008464.issue6106@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jackdied
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Mon May 25 21:01:20 2009
From: report at bugs.python.org (Marco)
Date: Mon, 25 May 2009 19:01:20 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243278080.68.0.395185130803.issue6070@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

TO georg.brandl:
I remembered that Windows wasn't POSIX compliant, but...I thought they
used the same sys/stat.h constants.
I was wrong :P

TO loewis:
ok, I've added a new patch.
Since I've never written any code for Windows, can you check if it works
fine now?
I've added a simple #ifdef WINDOWS,...

----------
keywords: +patch
Added file: http://bugs.python.org/file14069/import_patch2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Mon May 25 21:03:59 2009
From: report at bugs.python.org (Marco)
Date: Mon, 25 May 2009 19:03:59 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243278239.55.0.348420244114.issue6070@psf.upfronthosting.co.za>


Changes by Marco <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file14069/import_patch2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Mon May 25 21:04:08 2009
From: report at bugs.python.org (Marco)
Date: Mon, 25 May 2009 19:04:08 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243278248.22.0.804713438496.issue6070@psf.upfronthosting.co.za>


Changes by Marco <marcusbu at gmail.com>:


Added file: http://bugs.python.org/file14070/import_patch2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Mon May 25 21:21:40 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 25 May 2009 19:21:40 +0000
Subject: [issue5794] pickle/cPickle of recursive tuples create pickles that
	cPickle can't load
In-Reply-To: <1240170780.68.0.204813353535.issue5794@psf.upfronthosting.co.za>
Message-ID: <1243279300.31.0.949189853902.issue5794@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5794>
_______________________________________

From report at bugs.python.org  Mon May 25 21:32:20 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 25 May 2009 19:32:20 +0000
Subject: [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: <1243279940.9.0.150720906914.issue6022@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I think that one difference is build outside source tree. Not sure that
this is problem - the linker flags contain "... -L. -lpython2.7 ..." and
after change into another directory(temp) library is no more in current
directory.

Right now I'm too busy to look again into details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From report at bugs.python.org  Mon May 25 23:14:07 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 25 May 2009 21:14:07 +0000
Subject: [issue1761028] pickle - cannot unpickle circular deps with custom
	__hash__
Message-ID: <1243286047.84.0.482284899773.issue1761028@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Checked this out more throughly and I came to the conclusion this cannot
be fixed without a considerable amount of work.

The problem is pickle adds an Node instance stub in the next_nodes set
before its attributes are ready. Since the stub doesn't have any
attribute at the time its added to the set, the __hash__ method fails
with an AttributeError exception.

To fix this, pickle would need to detect cyclic objects with a custom
__hash__ method; and when it would see one, it would need to emit POP
opcodes to revert the parts of the object already pickled. And then,
pickle would have to re-pickle the cyclic object using a special
procedure that would delay the use of __hash__ until all the attributes
of the object are ready to be used.

I do not believe the bug arises frequently enough to justify adding more
tricky code to pickle. So, I will not fix this myself (feel free to
write a patch, however).

Finally, you can workaround the bug using the __getstate__/__setstate__
mechanism as follow:

class Node(object):
  def __init__(self, i):
    self.i = i
    self.next_nodes = set()
  def __cmp__(self, other):
	return cmp(self.i, other.i)
  def __hash__(self):
    return hash(self.i)
  def __getstate__(self):
    next_nodes = self.next_nodes.copy()
    next_nodes.discard(self)
    return {'i': self.i,
            'self_in_next_nodes': self in self.next_nodes,
            'next_nodes': next_nodes}
  def __setstate__(self, state):
    if state.pop('self_in_next_nodes'):
        self.__dict__.update(state)
        state['next_nodes'].add(self)
    else:
        self.__dict__.update(state)

n = Node(12)
n.next_nodes = set([n])

----------
assignee: alexandre.vassalotti -> 
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1761028>
_______________________________________

From report at bugs.python.org  Mon May 25 23:43:20 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 May 2009 21:43:20 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243287800.26.0.776004399289.issue6070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch of file 14070 doesn't compile, but I get the idea. I won't
have time to test it in the next few days or weeks, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

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: [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 02:38:24 2009
From: report at bugs.python.org (Vitaly Babiy)
Date: Tue, 26 May 2009 00:38:24 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1243298304.8.0.39779943765.issue5103@psf.upfronthosting.co.za>


Vitaly Babiy <vbabiy86 at gmail.com> added the comment:

Why not just remove the removal of the timeout.

----------
nosy: +vbabiy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Tue May 26 02:45:55 2009
From: report at bugs.python.org (Alex James)
Date: Tue, 26 May 2009 00:45:55 +0000
Subject: [issue6107] Subprocess.Popen output fails on Windows
In-Reply-To: <1243298755.35.0.185322237377.issue6107@psf.upfronthosting.co.za>
Message-ID: <1243298755.35.0.185322237377.issue6107@psf.upfronthosting.co.za>


New submission from Alex James <ac.james at shaw.ca>:

When calling p=subprocess.Popen(findstr "string" filename, stdout=PIPE)
both p.stdout.read() and p.communicate()[0] are returning None even when
the shell process has output (ie string was found in filename).  
Further, redirecting stdout to a file will write an empty file.  

I've got this result from running in script and on IDLE command line
with Python 2.6.2 on windows Vista home premuim and windows XP SP2
systems.  

Thinking this may be related to issue 1707753 or 1124861 I tried the
putting all streams to pipes workaround, but that also failed here.  

Using subprocess.call with stdout to file did work.  

This issue is primarily about the lack of cross-platform compatability
that the subprocess module was supposed to have, on unix systems the
base program I'm working with can call grep from any of os.popen,
popen2, or subprocess.Popen and work just fine.

----------
title: Pipes fail to return subprocess output on Windows -> Subprocess.Popen output fails on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6107>
_______________________________________

From report at bugs.python.org  Tue May 26 04:25:15 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 26 May 2009 02:25:15 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1243304715.83.0.874227561392.issue1559298@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

subprocess also needs this fix applied

Does the w9xopen command line below not need this?

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Tue May 26 04:31:34 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 26 May 2009 02:31:34 +0000
Subject: [issue6107] Subprocess.Popen output fails on Windows
In-Reply-To: <1243298755.35.0.185322237377.issue6107@psf.upfronthosting.co.za>
Message-ID: <1243305094.14.0.703011283148.issue6107@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

Exactly what command line are you passing to subprocess? Does stderr 
contain anything?

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6107>
_______________________________________

From report at bugs.python.org  Tue May 26 06:53:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 May 2009 04:53:19 +0000
Subject: [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 07:26:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 May 2009 05:26:16 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243315576.12.0.873656009886.issue6105@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

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: [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:53 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 06:51:53 +0000
Subject: [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:44 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 06:54:44 +0000
Subject: [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 08:55:24 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 06:55:24 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243320924.2.0.540942282383.issue6111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Changed into release blocker because this is a very visible and annoying 
issue.

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 09:00:45 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Tue, 26 May 2009 07:00:45 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243321245.04.0.550473291974.issue6105@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

This only seems to be the case with the C implementation of json (_json). 

>>> json.encoder.c_make_encoder = None
>>> json.dumps(OrderedDict(items))
'{"one": 1, "two": 2, "three": 3, "four": 4, "five": 5}'

I think the culprit is encoder_listencode_dict (Modules/_json.c:2049).
It uses PyDict_Next to fetch all items from the dictionary and thereby
loses order. A special code branch for dict subclasses
(!PyDict_CheckExact) which uses PyIter* instead should solve the
problem. (PyDict_Next should not honor order no matter what IMO.)

If nobody beats me to it I can try to come up with a patch.

----------
nosy: +lehmannro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Tue May 26 09:22:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 07:22:27 +0000
Subject: [issue6107] Subprocess.Popen output fails on Windows
In-Reply-To: <1243298755.35.0.185322237377.issue6107@psf.upfronthosting.co.za>
Message-ID: <1243322547.97.0.139881738324.issue6107@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The following works for me:

>>> import subprocess
>>> p=subprocess.Popen('findstr "disk" c:\\boot.ini',
stdout=subprocess.PIPE)
>>> print p.communicate()[0]
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect /NoExecute=OptOut

Tested with python2.5 on Windows XP, and python2.6 on Windows 2000

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6107>
_______________________________________

From report at bugs.python.org  Tue May 26 09:28:26 2009
From: report at bugs.python.org (Marco)
Date: Tue, 26 May 2009 07:28:26 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243322906.52.0.559147827131.issue6070@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

TO loewis: 
this new patch works fine.
I've removed the first #endif.

thank you ;)

----------
Added file: http://bugs.python.org/file14072/import_patch2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue May 26 09:47:43 2009
From: report at bugs.python.org (Ivo Danihelka)
Date: Tue, 26 May 2009 07:47:43 +0000
Subject: [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 09:50:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 May 2009 07:50:33 +0000
Subject: [issue6112] scheduler.cancel does not raise RuntimeError
In-Reply-To: <1243324062.93.0.51733568857.issue6112@psf.upfronthosting.co.za>
Message-ID: <1243324233.51.0.819289195516.issue6112@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r72932.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
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: [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 10:54:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 08:54:45 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243328085.66.0.138221328686.issue6111@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I tried with the latest version in py3k (r72934).
No problem for me on Windows 2000.

Did you try to run Idle from a shell window? Are there exceptions showing?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 10:58:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 08:58:41 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243328321.18.0.71627257378.issue6113@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you please show the code you tried initially?
I suspect that it always adds the same instance to the list...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 11:03:44 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 09:03:44 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243328624.18.0.685811951577.issue6111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I should have made this more clear in the description, instead of hiding 
it in the components list, but this is an issue for the OSX port.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 11:11:48 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 09:11:48 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243329108.6.0.552390548427.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

I didn't keep a copy of the code that didn't work.  Sorry.

When I changed the way I was initialising the classes, before adding
them to the list, I didn't change any of the logical flow in my code,
and it started to work.

I know it sounds very strange, like it really shouldn't happen, but it did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 11:22:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 09:22:41 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243329761.18.0.773517592437.issue6113@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

OK, then I'll close this issue.

This is probably a typo in your code, like this one that I make from
time to time:
    obj = Obj()
    Obj.sName = 'someName'

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 11:23:12 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 May 2009 09:23:12 +0000
Subject: [issue6109] IDLE rendering issue with oriental characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243329792.23.0.515291414076.issue6109@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Are these characters displayed correctly in other places?

Usually characters that are not available in a specific font are
replaced by an empty box. In some cases the missing characters can be
borrowed by other fonts, but IIRC that depends on the application.

If you have a script or file that demonstrates the problem, attach it to
the issue (I don't have OSX to test it though).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6109>
_______________________________________

From report at bugs.python.org  Tue May 26 11:34:20 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 09:34:20 +0000
Subject: [issue6109] IDLE rendering issue with oriental characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243330460.9.0.507641201479.issue6109@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The same fontname and file display correctly in programs (such as 
Textmate).

Even when both textmate and IDLE have been configured to use the same 
font the text looks fine in textmate and broken in IDLE.

My gut feeling is that this is an issue with the Tk port to OSX. 

The same bad output is seen in the GUI version of wish when you read the 
file there manually using this code:

% open /Users/ronald/Desktop/Chinese.txt
file10
% read file10


The output of the last statement also contains squares, and at the same 
positions as when I open the file in IDLE.

What I don't know is if there is some magical Tcl code that will fix 
this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6109>
_______________________________________

From report at bugs.python.org  Tue May 26 11:48:22 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 09:48:22 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243331302.96.0.620465718158.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

Trust me this was no typo.

I debugged my code by adding print statements to see what values were
going into the list, and print statements to see the values that were
coming out.

It might be that running code from the application Blender does bazaar
things, or it could be anything, I don't know.  All I know is all the
instances I had in the list, had the same property values as the last
element that was added to the list.  I know it's amazingly weird.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 12:05:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 May 2009 10:05:01 +0000
Subject: [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: <1243332301.78.0.639839303544.issue6102@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Your problem could be related to #3297, but katakana characters don't
have a codepoint greater than U+FFFF so it could be something else.
(What is the value of sys.maxunicode there though?)

I tried your script on Linux with Python3.1b1 and en_US.UTF-8 but I
wasn't able to reproduce the issue.
I ran the script from the terminal with "python3 test.py" twice and it
worked both the time (is this the correct way to use the script?).
Can you try with Python3.1 and see if it works?

I also tried to create a directory called ?????? with an
__init__.py in it, I imported it and reloaded and it worked properly,
even when the .pyc was there.

If you delete the .pyc an reload the script again, does it work?

(Next time upload the files separately, it's easier for us to see them.)

----------
components: +Unicode -None
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6102>
_______________________________________

From report at bugs.python.org  Tue May 26 12:23:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 May 2009 10:23:11 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243333391.25.0.402103019726.issue6113@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Even if it's a real bug, without the code we can't do anything.
Try to reproduce what you did or get that code back somehow (ctrl+z? ;)

----------
nosy: +ezio.melotti

_______________________________________
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: [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 12:59:37 2009
From: report at bugs.python.org (jougs)
Date: Tue, 26 May 2009 10:59:37 +0000
Subject: [issue6114] distutils build_ext path comparison only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1243335577.16.0.00779854484785.issue6114@psf.upfronthosting.co.za>


Changes by jougs <jochen.eppler at gmx.de>:


----------
nosy: +jougs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6114>
_______________________________________

From report at bugs.python.org  Tue May 26 13:30:57 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 11:30:57 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243337457.6.0.162241785861.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

First File....


This is the main one, it's the one that is called from the Blender
application.

----------
Added file: http://bugs.python.org/file14074/MyWalls.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 13:31:44 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 11:31:44 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243337504.6.0.732393345032.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

Second file....

The loads of code for building a wall

----------
Added file: http://bugs.python.org/file14075/WallWithDoors.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 13:32:21 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 11:32:21 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243337541.5.0.16714240741.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

Third file...

all the classes for holding the data

----------
Added file: http://bugs.python.org/file14076/modDataObjects.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 13:33:48 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 11:33:48 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243337628.39.0.713754608375.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

Forth and final file...

Just a little error handling and stuff I want all my classes to inherit

----------
Added file: http://bugs.python.org/file14077/modBasics.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 13:40:11 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 11:40:11 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243338011.46.0.493788604729.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

If you want to run it I'm afraid you'll have to:
1) install Blender (www.blender.org)
2) put all those files in C:\Program Files\Blender
Foundation\Blender\.blender\scripts\MyWalls\src\
3) in the Blender application goto scripts ---> Objects ---> Build Walls

Then look at the terminal window that comes with Blender and you'll see
it's just gone wrong.

And if you change the Class ClsFeatureVariables, so that the properties
are set when it initialises you'll see it all works OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 13:43:17 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 11:43:17 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243338197.4.0.970642476659.issue6113@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's a typo :-)
In WallWithDoors.py, line 146:
                    cTempVariable = ClsFeatureVariable
You forgot the () at the end...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 14:00:50 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 12:00:50 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243339250.63.0.243430026444.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

So why is it able to create instances and add them to the
lstFeatureVariables list, surely it should go wrong there and not allow
the instances to be created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 14:01:39 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 12:01:39 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243339299.14.0.96794641927.issue6113@psf.upfronthosting.co.za>


Matthew <matthew.baynham at gmail.com> added the comment:

OK, sorry for the rambling, just ignore it....

Cheers.......

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

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: [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 14:14:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 12:14:30 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243340070.53.0.344802764281.issue6113@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 14:32:18 2009
From: report at bugs.python.org (Marco)
Date: Tue, 26 May 2009 12:32:18 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243341138.56.0.409576797605.issue6070@psf.upfronthosting.co.za>


Changes by Marco <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file14049/import_patch.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue May 26 14:32:22 2009
From: report at bugs.python.org (Marco)
Date: Tue, 26 May 2009 12:32:22 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243341142.39.0.763725123067.issue6070@psf.upfronthosting.co.za>


Changes by Marco <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file14070/import_patch2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue May 26 14:38:00 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 26 May 2009 12:38:00 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243341480.46.0.504538534328.issue6105@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I can't see that the order of keys should matter for language-neutral
serialization libs like json or xmlrpclib.  You're quite possibly
going to be communicating with something on the other end which doesn't
have an OrderedDict-like class.  Why add the extra complication to the
library?

Even with Python of recent enough vintage at both ends, I can't see
that you could dumps() an OrderedDict then loads() the resulting
string and get an OrderedDict out as a result.  You should get a dict,
right?

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Tue May 26 14:44:25 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 12:44:25 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243341865.02.0.695426275261.issue6113@psf.upfronthosting.co.za>


Changes by Matthew <matthew.baynham at gmail.com>:


Removed file: http://bugs.python.org/file14074/MyWalls.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 14:44:30 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 12:44:30 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243341870.37.0.727808085057.issue6113@psf.upfronthosting.co.za>


Changes by Matthew <matthew.baynham at gmail.com>:


Removed file: http://bugs.python.org/file14075/WallWithDoors.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 14:44:35 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 12:44:35 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243341875.7.0.730178065441.issue6113@psf.upfronthosting.co.za>


Changes by Matthew <matthew.baynham at gmail.com>:


Removed file: http://bugs.python.org/file14076/modDataObjects.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From report at bugs.python.org  Tue May 26 14:44:40 2009
From: report at bugs.python.org (Matthew)
Date: Tue, 26 May 2009 12:44:40 +0000
Subject: [issue6113] Dupicate instances of classes in list
In-Reply-To: <1243328043.86.0.156653383974.issue6113@psf.upfronthosting.co.za>
Message-ID: <1243341880.75.0.337131493694.issue6113@psf.upfronthosting.co.za>


Changes by Matthew <matthew.baynham at gmail.com>:


Removed file: http://bugs.python.org/file14077/modBasics.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6113>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May 12 12:21:18 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: Tue, 12 May 2009 10:21:18 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1242123678.04.0.985607001686.issue5201@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The patch looks good, beside the fact that you didn't call super() in
setUp/tearDown.

I'll commit it asap and fix that small issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5201>
_______________________________________

From =?utf-8?q?Denilson_Figueiredo_de_S=C3=A1_=3Creport=40bugs=2Epython=2Eorg?= at psf.upfronthosting.co.za  Tue May 12 17:21:34 2009
From: =?utf-8?q?Denilson_Figueiredo_de_S=C3=A1_=3Creport=40bugs=2Epython=2Eorg?= at psf.upfronthosting.co.za (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1_=3Creport=40bugs=2Epython=2Eorg?= at psf.upfronthosting.co.za)
Date: Tue, 12 May 2009 15:21:34 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1242141694.41.0.920982101603.issue4947@psf.upfronthosting.co.za>


Changes by Denilson Figueiredo de S? <denilsonsa at gmail.com>:


----------
nosy: +denilsonsa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May 12 19:17:21 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: Tue, 12 May 2009 17:17:21 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242148641.57.0.10825120538.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72585 and propagated in 2.6, 3.0, 3.1 branches

Thank you !

----------
status: open -> closed
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May 12 19:19:32 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: Tue, 12 May 2009 17:19:32 +0000
Subject: [issue5164] backport distutils 3.x changes into 2.7 when appliabl
In-Reply-To: <1233911195.36.0.922992904897.issue5164@psf.upfronthosting.co.za>
Message-ID: <1242148772.26.0.700501272837.issue5164@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I don't need a ticket for this I guess, it's done progressively

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5164>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May 12 19:22:28 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: Tue, 12 May 2009 17:22:28 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1242148948.89.0.758508380094.issue1180@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am taking over this issue (I am figuring out you are OK with this
Martin) and put it in my work pile so it goes in 2.7

----------
assignee: loewis -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May 12 20:22:47 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 12 May 2009 18:22:47 +0000
Subject: [issue2856] os.listdir doc should mention that Unicode decoding can
	fail
In-Reply-To: <1210814208.45.0.272157928062.issue2856@psf.upfronthosting.co.za>
Message-ID: <1242152567.2.0.998609938884.issue2856@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2856>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May 12 20:35:11 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 12 May 2009 18:35:11 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1242153311.99.0.192128921033.issue3872@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If you follow-up to a closed issue, your follow-up inevitably gets ignored.

Please understand that the issue you encountered is completely different
from the one reported here (which was about the Windows build).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue May 12 20:38:58 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 12 May 2009 18:38:58 +0000
Subject: [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: <1242153538.02.0.594195077191.issue5999@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have two questions:
1. does your system provide the mbstate_t type?
2. if so, what header file needs to be included?

Also, please confirm a few things:
a. configure has detected that your system has mbrtowc
b. configure's analysis is correct, i.e. your system has mbrtowc indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May 13 00:09:19 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: Tue, 12 May 2009 22:09:19 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242166159.75.0.595628652468.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Sorry about that, I was travelling and didn't see that the buildbots
turned red. (I ran the test but didn't build python again)

I have changed that because build_ext.compiler is a string option, e.g.
the compiler type. Turning it into a compiler instance when the command
is run twice it breaks  because it is used as a string argument to
create a compiler.

Maybe a solution would be to rename the option name into "compiler_type"
and keep build_ext.compiler as a compiler instance.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May 13 05:03:38 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 13 May 2009 03:03:38 +0000
Subject: [issue6007] distutils tricks you into thinking you can
	build	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <4A0A3885.5020606@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 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.

----------
nosy: +loewis
title: distutils tricks you into thinking you can build extensions with mingw -> distutils tricks you into thinking you can build	extensions with mingw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May 13 09:55:56 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: Wed, 13 May 2009 07:55:56 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242201356.36.0.774584120962.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

new_compiler takes "compiler" as a compiler name. It would make much
sense to make it accept a compiler instance.

now for people setup.py, I wasn't aware that people are using
build_ext.compiler as a compiler, besides Python itself.

IMHO we should rename the compiler option to "compiler_type" then
provide an API build_ext.get_compiler() then fix Python setup.py file.

Then this should not go into 2.6 but in 2.7, and we should put back the
option in new_compiler like it was (it's wrong but at least it works if
you run the command just once, which is the most common case)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Wed May 13 10:12:47 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: Wed, 13 May 2009 08:12:47 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242202367.61.0.746387910416.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

typo: 

It would make much... -> It would not make much...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May 13 20:37:34 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 13 May 2009 18:37:34 +0000
Subject: [issue6010] unable to retrieve latin-1 encoded data from sqlite3
In-Reply-To: <1242210908.7.0.745434418713.issue6010@psf.upfronthosting.co.za>
Message-ID: <1242239854.47.0.065819326354.issue6010@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug. By default, pysqlite decodes all strings to Unicode,
assuming UTF-8 encoding (which SQLite assumes when parsing statements).

To override this default, you need to change the connection's text_factory:

py> import sqlite3
py> db = sqlite3.connect(':memory:')
py> db.text_factory = str
py> cur = db.cursor()
py> cur.execute("create table foo (x)")
<sqlite3.Cursor object at 0xb7cfb500>
py> cur.execute("insert into foo values ('caf?')")
<sqlite3.Cursor object at 0xb7cfb500>
py> cur.execute("select * from foo")
<sqlite3.Cursor object at 0xb7cfb500>
py> _.fetchall()
[('caf\xe9',)]

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6010>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May 13 20:44:50 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 13 May 2009 18:44:50 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242240290.87.0.659111575293.issue6012@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I would propose a different approach: the same function can be both
argument parser and cleanup function. In parsing, the PyObject* points
to the parameter being converted. In cleanup, it points to NULL.

This would allow the O& to continue to be used even if cleanup is
needed. As not all converters would need or support cleanup, converters
that do need cleanup could be required to return Py_CLEANUP_SUPPORTED
(which would be, say, 131072).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May 13 20:47:47 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 13 May 2009 18:47:47 +0000
Subject: [issue6007] distutils tricks you into thinking you can	build
	extensions with mingw
In-Reply-To: <1242216875.23.0.554007199202.issue6007@psf.upfronthosting.co.za>
Message-ID: <4A0B15CE.3010006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I think this is exaggerating the actual state. The compiler is
>> certainly supported.
> 
> Can you elaborate on what "supported" means?  To me, it would mean that
> it could build all the same Python extensions which MSVC can build.

"Supported" means that it will invoke the compiler with the right
command line arguments.

It can't possibly mean what you suggest: gcc simply cannot compile all
code that MSVC can compile - in particular, will will not support many
of the VC extensions to C that a Python extension module may use. COM
interfaces are particularly difficult, making it fail on, e.g. PyWin32.
This was always the case, and never stopped people contributing mingw
support.

----------
title: distutils tricks you into thinking you can build	extensions with mingw -> distutils tricks you into thinking you can	build extensions with mingw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May 13 22:38:54 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 13 May 2009 20:38:54 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1242245141.48.0.021861166145.issue1621@psf.upfronthosting.co.za>
Message-ID: <4A0B2FD9.9060504@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm finding many overflow checks that look like:
> 
> 	size = Py_SIZE(a) * n;
> 	if (n && size / n != Py_SIZE(a)) {
> 		PyErr_SetString(PyExc_OverflowError,
> 			"repeated bytes are too long");
> 		return NULL;
> 	}
> 
> where size and n have type Py_ssize_t.  That particular one comes
> from bytesobject.c (in py3k), but this style of check occurs
> frequently throughout the source.
> 
> Do people think that all these should be fixed?  

If this really invokes undefined behavior already (i.e. a compiler
could set "size" to -1, and have the test fail - ie. not give
an exception, and still be conforming) - then absolutely yes.

> The fix itself s reasonably straightforward:  instead of multiplying
> and then checking for an overflow that's already happened (and hence
> has already invoked undefined behaviour according to the standards),
> get an upper bound for n *first* by dividing PY_SSIZE_T_MAX
> by Py_SIZE(a) and use that to do the overflow check *before*
> the multiplication.  It shouldn't be less efficient:  either way
> involves an integer division, a comparison, and a multiplication.

[and then perform the multiplication unsigned, to silence the
warning - right?]

I think there is a second solution: perform the multiplication
unsigned in the first place. For unsigned multiplication, IIUC,
overflow behavior is guaranteed in standard C (i.e. it's modulo
2**N, where N is the number of value bits for the unsigned value).

So the code would change to

nbytes = (size_t)Py_SIZE(a)*n;
if (n && (nbytes > Py_SSIZE_T_MAX || nbytes/n != Py_SIZE(a))...
size = (Py_ssize_t)nbytes;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Wed May 13 23:32:42 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Wed, 13 May 2009 21:32:42 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1242248309.07.0.900383605185.issue1621@psf.upfronthosting.co.za>
Message-ID: <4A0B3C75.3040104@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 	size = Py_SIZE(a) * n;
> 
> The multiplication should be safe from overflow, and I don't get
> any warning at all either with this rewrite (using -O3 -Wall -Wextra -
> Wsigned-overflow=5) or from the original code, so there's nothing to 
> silence.

This is puzzling, isn't it? It *could* overflow, could it not?

>> I think there is a second solution: perform the multiplication
>> unsigned in the first place.
> 
> That would work too.  I find the above code clearer, though.

I agree in this case. In general, I'm not convinced that it
is always possible to rewrite the code in that way conveniently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 14 12:57:58 2009
From: =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Thu, 14 May 2009 10:57:58 +0000
Subject: [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1242298678.76.0.846855785273.issue1866@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

The patch no longer applies cleanly to the trunk.

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 14 22:22:32 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: Thu, 14 May 2009 20:22:32 +0000
Subject: [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: <1242332552.18.0.885739253773.issue6022@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72636, r72637, r72638, r72639

----------
components: +Distutils
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 14 22:27:21 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: Thu, 14 May 2009 20:27:21 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
	(patch)
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1242332841.74.0.87922418083.issue5977@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Roumen, the problem you mentioned was existing because of the
empty c file in test_get_outputs. I have fixed it yesterday by creating a
simple c file containing a minimal code:

void inifoo(void) {};

can you check it works for you ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5977>
_______________________________________

From =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 14 22:44:40 2009
From: =?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Walter_D=C3=B6rwald_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Thu, 14 May 2009 20:44:40 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1242333880.43.0.699565751061.issue2661@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Any custom mapping class should have a repr test anyway, so IMHO it
doesn't matter whether the base test has a repr test or not.

The suggested fixes for TestMappingProtocol.test_fromkeys() and
TestHashMappingProtocol.test_mutatingiteration() sound OK however.

David, can you provide a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 14 23:58:30 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: Thu, 14 May 2009 21:58:30 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1242338310.63.0.0574671632992.issue6011@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks, I'll work on this during this week end hopefully

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 15 00:05:00 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Thu, 14 May 2009 22:05:00 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242304155.9.0.228985349233.issue6012@psf.upfronthosting.co.za>
Message-ID: <4A0C9586.6090409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, this is not implemented yet. (I introduced another format
> temporary) Does this mean converter should return Py_CLEANUP_SUPPORTED
> instead of 1 when cleanup is needed?

If you are introducing a new character ($), then this isn't actually
needed. I was thinking of reusing O&, literally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From =?utf-8?b?QW5kcsOpcyBNYXJ6YWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Sat May 16 11:45:48 2009
From: =?utf-8?b?QW5kcsOpcyBNYXJ6YWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?QW5kcsOpcyBNYXJ6YWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Sat, 16 May 2009 09:45:48 +0000
Subject: [issue6037] MutableSequence.__iadd__ should return self
In-Reply-To: <1242467148.54.0.030236085026.issue6037@psf.upfronthosting.co.za>
Message-ID: <1242467148.54.0.030236085026.issue6037@psf.upfronthosting.co.za>


New submission from Andr?s Marzal <amarzal at lsi.uji.es>:

I've implemented a LinkedList as a MutableSequence and __iadd__, which
is inherited from MutableSequence, does not perform as expected.
The _abcoll.py file contains this:

class MutableSequence(Sequence):
     ...
   def __iadd__(self, values):
       self.extend(values)

The method __iadd__ does not return anything, buy it should return
self. Right now, the sentence

aLinkedList += [1, 2]

sets the value of aLinkedList to None.

----------
components: Library (Lib)
messages: 87872
nosy: amarzal
severity: normal
status: open
title: MutableSequence.__iadd__ should return self
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6037>
_______________________________________

From =?utf-8?b?QW5kcsOpcyBNYXJ6YWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Sat May 16 11:46:31 2009
From: =?utf-8?b?QW5kcsOpcyBNYXJ6YWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?QW5kcsOpcyBNYXJ6YWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Sat, 16 May 2009 09:46:31 +0000
Subject: [issue6037] MutableSequence.__iadd__ should return self
In-Reply-To: <1242467148.54.0.030236085026.issue6037@psf.upfronthosting.co.za>
Message-ID: <1242467191.23.0.450942980186.issue6037@psf.upfronthosting.co.za>


Andr?s Marzal <amarzal at lsi.uji.es> added the comment:

I've implemented a LinkedList as a MutableSequence and __iadd__, which
is inherited from MutableSequence, does not perform as expected.
The _abcoll.py file contains this:

class MutableSequence(Sequence):
     ...
   def __iadd__(self, values):
       self.extend(values)

The method __iadd__ does not return anything, buy it should return
self. Right now, the sentence

aLinkedList += [1, 2]

sets the value of aLinkedList to None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6037>
_______________________________________

From =?utf-8?q?Hagen_F=C3=BCrstenau_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May 16 11:55:35 2009
From: =?utf-8?q?Hagen_F=C3=BCrstenau_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Hagen_F=C3=BCrstenau_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Sat, 16 May 2009 09:55:35 +0000
Subject: [issue6038] Should collections.Counter check for int?
In-Reply-To: <1242467735.26.0.543140377658.issue6038@psf.upfronthosting.co.za>
Message-ID: <1242467735.26.0.543140377658.issue6038@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

I noticed that while the docs say that "Counts are allowed to be
any integer value including zero or negative counts",
collections.Counter doesn't perform any check on the types of count
values. Instead, non-numerical values will lead to strange behaviour or
exceptions later on:

>>> c = collections.Counter({'a':'3', 'b':'20', 'c':'100'})
>>> c.most_common(2)
[('a', '3'), ('b', '20')]
>>> c+c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/local/hagenf/lib/python3.1/collections.py", line 467, in __add__
    if newcount > 0:
TypeError: unorderable types: str() > int()

I'd prefer Counter to refuse non-numerical values right away as the
present behaviour may hide bugs (e.g. a forgotten string->int
conversion). Any opinions? (And what about negative values or floats?)

----------
components: Library (Lib)
messages: 87874
nosy: hagen
severity: normal
status: open
title: Should collections.Counter check for int?
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6038>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May 16 18:27:45 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, 16 May 2009 16:27:45 +0000
Subject: [issue6041] change sdist and register command so they use check
In-Reply-To: <1242491265.74.0.368727644802.issue6041@psf.upfronthosting.co.za>
Message-ID: <1242491265.74.0.368727644802.issue6041@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

the check command now is able to check the meta-data, so we can remove
duplicate code located in both "sdist" and "register" and call "check as
a subcommand.

- register will also have a new boolean option called "strict". If set
to True (it's unset by default), register will stop if the metadata are
not OK or if the long_description fails to compile in reST (as long as
docutils is installed of course)

- sdist will have a new boolean option called "medata-check", set to
true by default. That will use "check" to verify the metadata (not the 
long_description reSt compliancy though, just the metadata fields presence)

----------
assignee: tarek
components: Distutils
messages: 87900
nosy: tarek
severity: normal
status: open
title: change sdist and register command so they use check
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6041>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May 16 18:29:38 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, 16 May 2009 16:29:38 +0000
Subject: [issue6041] change sdist and register command so they use check
In-Reply-To: <1242491265.74.0.368727644802.issue6041@psf.upfronthosting.co.za>
Message-ID: <1242491378.05.0.415818443409.issue6041@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

the old check_metadata method, duplicated in sdist and register, will be
marked with a PendingDeprecationWarning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6041>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May 16 18:49:32 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, 16 May 2009 16:49:32 +0000
Subject: [issue5732] add a new command called "check" into Distutils
In-Reply-To: <1239318936.64.0.115245902927.issue5732@psf.upfronthosting.co.za>
Message-ID: <1242492572.88.0.246407868497.issue5732@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

closing (created a new ticket #6041 for sdist and register inclusion)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5732>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May 16 18:49:50 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, 16 May 2009 16:49:50 +0000
Subject: [issue5732] add a new command called "check" into Distutils
In-Reply-To: <1239318936.64.0.115245902927.issue5732@psf.upfronthosting.co.za>
Message-ID: <1242492590.68.0.588939534084.issue5732@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
dependencies: +change sdist and register command so they use check

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5732>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sat May 16 19:01:09 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, 16 May 2009 17:01:09 +0000
Subject: [issue6041] change sdist and register command so they use check
In-Reply-To: <1242491265.74.0.368727644802.issue6041@psf.upfronthosting.co.za>
Message-ID: <1242493269.12.0.621862078554.issue6041@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72681, r72683

----------
dependencies: +add a new command called "check" into Distutils
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6041>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May 16 20:40:24 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 16 May 2009 18:40:24 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1242291620.45.0.0551263828295.issue1621@psf.upfronthosting.co.za>
Message-ID: <4A0F0894.3040804@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't see why.  There's nothing in -Wall -Wextra -Wsigned-overflow
> that asks for warnings for code that might overflow.

Ah, right. I misunderstood (rather, didn't bother checking) what
-Wsigned-overflow really does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May 16 23:08:58 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 16 May 2009 21:08:58 +0000
Subject: [issue3527] Py_WIN_WIDE_FILENAMES removal
In-Reply-To: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
Message-ID: <1242508138.12.0.920918317983.issue3527@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looks fine to me, please apply.

----------
assignee:  -> ocean-city
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3527>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 06:36:48 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 04:36:48 +0000
Subject: [issue4126] remove not decodable environment variables
In-Reply-To: <1224031525.89.0.11832939128.issue4126@psf.upfronthosting.co.za>
Message-ID: <1242535008.45.0.467965569652.issue4126@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This patch is out of date with PEP 383

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4126>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 07:00:45 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 05:00:45 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242536444.85.0.473363477653.issue6012@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 08:08:23 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 06:08:23 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1242540503.96.0.91951462971.issue4856@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is slightly out of date; if updated, it is fine to apply after
3.1.

I think Py_GetFileAttributesExA can also be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 09:06:56 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 07:06:56 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1242544016.09.0.669458526622.issue6012@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Modifying convert_to_unicode is incorrect; this function is not an O&
converter. Instead, PyUnicode_FSConverter needs to change.

Attached is a patch that does that, and also uses the O& approach. It
also adjusts the patch to use capsules.

----------
Added file: http://bugs.python.org/file13997/conv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 17 11:56:54 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, 17 May 2009 09:56:54 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242554214.36.0.483321886504.issue6046@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

When I made this change I checked it under VC9, so it should work on
this version.

I'll have to create a VM with VC6 to track it down.
Until then I'll deactivate this test when it's VC6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 17 12:18:44 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, 17 May 2009 10:18:44 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242555524.89.0.0245974151507.issue6046@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok done. can you check on your side ? 

Don't we have a win32+MVCS6 buildslave somewhere ?

That would be nice to have.

I am running 3 differents VMs already when I work on these files. It
would be great to have buildbot making regression tests over all
compiler flavors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 12:55:40 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 10:55:40 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242549682.08.0.573082695779.issue6012@psf.upfronthosting.co.za>
Message-ID: <4A0FED27.8040205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, convert_to_unicode used to use O& before

I don't understand. Where does it use it? Before
your patch, convert_to_unicode was a regular one-argument
function, not a ParseTuple O& function. Only your patch
makes it one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 13:05:36 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 11:05:36 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <4A0FEF7B.9060301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 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.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 13:58:26 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 11:58:26 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242560007.47.0.980844872261.issue6045@psf.upfronthosting.co.za>
Message-ID: <4A0FFBDE.4020808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> 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.
> 
> Supporting only __getitem__, __setitem__, __delitem__, __contains__ and
> keys is already "most of a dict-style interface"? 

It's also __len__... Indeed, I think that this is the major part of the
dict interface. For a number of additional methods, it would be
straight-forward to support them as well (such as get(), pop(),
popitem(), setdefault(), update()). That they are missing should be
considered as a regular bug/missing feature. However, it appears that
nobody has complained about those missing features in all these years,
so that they are missing can't be that serious.

> However, for the dbm modules I would be in favor of only specifying the
> four mentioned methods, as in the docstring of dbm/__init__.py, and not
> claiming any more.

I don't mind the documentation to explain precisely what is, as long as
it continues to explain what could be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Sun May 17 14:19:55 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, 17 May 2009 12:19:55 +0000
Subject: [issue6048] make distutils use the tarinfo command
In-Reply-To: <1242562795.38.0.0774270839785.issue6048@psf.upfronthosting.co.za>
Message-ID: <1242562795.38.0.0774270839785.issue6048@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Currently Distutils uses the "tar" command to build tarballs. 

It's better to use the tarinfo module, so Distutils does not depend on
the "tar" program anymore.

----------
assignee: tarek
components: Distutils
messages: 87994
nosy: tarek
severity: normal
status: open
title: make distutils use the tarinfo command
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6048>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 16:52:57 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 14:52:57 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242562510.63.0.838845133048.issue6045@psf.upfronthosting.co.za>
Message-ID: <4A1024C5.2020800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Would inheriting from MutableMapping fix this problem?

In principle: some of it, yes. These types are written in C,
so I'm not sure how exactly it would work. Also, it
still wouldn't provide all methods, e.g. copy(), fromkeys(),
get(), values(), items() would still be missing, as would
iteration (although the dict documentation apparently never
says that iterating over a dict is supported).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sun May 17 21:15:46 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sun, 17 May 2009 19:15:46 +0000
Subject: [issue6049] str.strip() and " behaviour expected?
In-Reply-To: <1242586136.29.0.143891828835.issue6049@psf.upfronthosting.co.za>
Message-ID: <1242587746.01.0.558130398571.issue6049@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6049>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May 18 08:14:54 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 18 May 2009 06:14:54 +0000
Subject: [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: <1242627293.81.0.954428187161.issue6050@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> loewis
nosy: +loewis
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6050>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May 18 10:12:58 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: Mon, 18 May 2009 08:12:58 +0000
Subject: [issue6046] test_distutils.py fails on VC6(Windows)
In-Reply-To: <1242550207.81.0.872664321931.issue6046@psf.upfronthosting.co.za>
Message-ID: <1242634378.42.0.477177801599.issue6046@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks Roumen,that was it. I've commited the change and added a test to
verify the produced file has the right extension.

Thanks for the feedback Hirokazu

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6046>
_______________________________________

From =?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson_=3Creport=40bugs=2Epython=2Eor?= at psf.upfronthosting.co.za  Mon May 18 11:24:43 2009
From: =?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson_=3Creport=40bugs=2Epython=2Eor?= at psf.upfronthosting.co.za (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson_=3Creport=40bugs=2Epython=2Eor?= at psf.upfronthosting.co.za)
Date: Mon, 18 May 2009 09:24:43 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1242638683.65.0.287434042119.issue4174@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Perhaps not.
I had however written a general list locking system, generalizing the 
way sort() locks a list for direct manipulation, and rewritten min and 
max to be able to use that.  Perhaps that approach would be of interest?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May 18 13:17:26 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: Mon, 18 May 2009 11:17:26 +0000
Subject: [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <1242645446.65.0.222882949515.issue6053@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am currently working on the removal of 'tar' in favor of the usage of
tarinfo, so I'll get back to you in this issue when it's ready

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6053>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May 18 13:18:25 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: Mon, 18 May 2009 11:18:25 +0000
Subject: [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <1242645505.64.0.028144456066.issue6053@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

(and also fix the test in 2.6 for this case)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6053>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Mon May 18 14:31:52 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: Mon, 18 May 2009 12:31:52 +0000
Subject: [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <1242649912.99.0.719202862215.issue6053@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok done, thanks for the patch;

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6053>
_______________________________________

From =?utf-8?b?SmVzw7pzIENlYSBBdmnDs24gPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Mon May 18 21:57:54 2009
From: =?utf-8?b?SmVzw7pzIENlYSBBdmnDs24gPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24gPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Mon, 18 May 2009 19:57:54 +0000
Subject: [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1242676674.89.0.196860178692.issue3541@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Python 2.5 is in security maintenance mode only.

Please, upgrade to Python 2.6. If you can not upgrade Python, install a
recent bsddb release from http://www.jcea.es/programacion/pybsddb.htm

If you can still reproduce the problem, let me know.

----------
assignee:  -> jcea
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May 18 22:16:40 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 18 May 2009 20:16:40 +0000
Subject: [issue6053] distutils error on windows
In-Reply-To: <1242644871.4.0.222185157282.issue6053@psf.upfronthosting.co.za>
Message-ID: <4A11C224.7010907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 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.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6053>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May 18 22:29:09 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 18 May 2009 20:29:09 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <1242651062.23.0.881837774389.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4A11C511.8040304@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would appreciate if someone could review the patch and comment on the
> technique.

There are a few minor issues; overall, it looks correct:
- the test for "this is windows" should just use MS_WINDOWS.
- don't declare variables in the middle of a block; we use C89.
- the argument parsing looks incorrect; take a look at rename()
  for guidance. Supporting bytes is optional; IMO, requiring
  Unicode strings for the API would be fine.

I don't quite understand why you can't implement lstat, or why
you would want to call into ntpath. Take a look at how stat()
is implemented in the nt module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Mon May 18 22:31:43 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Mon, 18 May 2009 20:31:43 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1242678703.11.0.851535028752.issue6054@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za  Tue May 19 02:09:05 2009
From: =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za (=?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za)
Date: Tue, 19 May 2009 00:09:05 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1242691745.04.0.661409156689.issue1602@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Just in case it helps, this behaviour is on Win XP Pro, Python 2.5.1:

First, I added an alias for 'cp65001' to 'utf_8' in
Lib/encodings/aliases.py .

Then, I opened a command prompt with a bitmap font.

c:\windows\system32>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print u"\N{EM DASH}"
???

I switched the font to Lucida Console, and retried (without exiting the
python interpreter, although the behaviour is the same when exiting and
entering again: )

>>> print u"\N{EM DASH}"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied

Then I tried (by pressing Alt+0233 for ?, which is invalid in my normal
cp1253 codepage):

>>> print u"n?e"

and the interpreter exits without any information. So it does for:

>>> a=u"n?e"

Then I created a UTF-8 text file named 'test65001.py':

# -*- coding: utf_8 -*-
a=u"n?e?"
print a

and tried to run it directly from the command line:

c:\windows\system32>python d:\src\PYTHON\test65001.py
n?e?Traceback (most recent call last):
  File "d:\src\PYTHON\test65001.py", line 4, in <module>
    print a
IOError: [Errno 2] No such file or directory

You see? It printed all the characters before failing.

Also the following works:

c:\windows\system32>echo he??
he??

and

c:\windows\system32>echo he?? >D:\src\PYTHON\dummy.txt

creates successfully a UTF-8 file (without any UTF-8 BOM marks at the
beginning).

So it's possible that it is a python bug, or at least something can be
done about it.

----------
nosy: +tzot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za  Tue May 19 02:21:34 2009
From: =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za (=?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za)
Date: Tue, 19 May 2009 00:21:34 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

Add 'cp65001' (Microsoft term for UTF-8) as an alias to 'utf_8'

----------
components: Library (Lib), Unicode
files: alias_cp65001.diff
keywords: patch
messages: 88060
nosy: tzot
severity: normal
status: open
title: Add cp65001 to encodings/aliases.py
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14013/alias_cp65001.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za  Tue May 19 02:21:57 2009
From: =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za (=?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za)
Date: Tue, 19 May 2009 00:21:57 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1242692517.89.0.100977522188.issue6058@psf.upfronthosting.co.za>


Changes by ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za  Tue May 19 02:23:03 2009
From: =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za (=?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za)
Date: Tue, 19 May 2009 00:23:03 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1242692583.88.0.376903579025.issue6058@psf.upfronthosting.co.za>


Changes by ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14013/alias_cp65001.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za  Tue May 19 02:24:04 2009
From: =?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za (=?utf-8?b?Is6nz4HOrs+Dz4TOv8+CIM6TzrXPic+BzrPOr86/z4UgXChDaHJpc3RvcyBH?= at psf.upfronthosting.co.za)
Date: Tue, 19 May 2009 00:24:04 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1242692644.96.0.83108216646.issue6058@psf.upfronthosting.co.za>


Changes by ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:


Added file: http://bugs.python.org/file14014/alias_cp65001.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May 19 17:56:35 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: Tue, 19 May 2009 15:56:35 +0000
Subject: [issue6062] build_ext fails to build in the right directory using the
	package option
In-Reply-To: <1242748595.33.0.217120074427.issue6062@psf.upfronthosting.co.za>
Message-ID: <1242748595.33.0.217120074427.issue6062@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

all in the title. currently working to fix this.

----------
assignee: tarek
components: Distutils
messages: 88080
nosy: tarek
severity: normal
status: open
title: build_ext fails to build in the right directory using the package option
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6062>
_______________________________________

From =?utf-8?q?Tarek_Ziad=C3=A9_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Tue May 19 18:17:48 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: Tue, 19 May 2009 16:17:48 +0000
Subject: [issue6062] build_ext fails to build in the right directory using the
	package option
In-Reply-To: <1242748595.33.0.217120074427.issue6062@psf.upfronthosting.co.za>
Message-ID: <1242749868.49.0.511646261391.issue6062@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72781

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6062>
_______________________________________

From =?utf-8?q?Gerhard_H=C3=A4ring_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 21 00:30:09 2009
From: =?utf-8?q?Gerhard_H=C3=A4ring_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Gerhard_H=C3=A4ring_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Wed, 20 May 2009 22:30:09 +0000
Subject: [issue6057] sqlite3 error classes should be documented
In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za>
Message-ID: <1242858609.44.0.240600294741.issue6057@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

At the very start of the module's documentation it reads:

"""
pysqlite was written by Gerhard H?ring and provides a SQL interface
compliant with the DB-API 2.0 specification described by PEP 249.
"""

Where "PEP 249" is a link to the Database API 2.0 specification, which
does document the xception classes and their hierarchy.

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6057>
_______________________________________

From =?utf-8?b?TGFycyBHdXN0w6RiZWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Thu May 21 11:18:39 2009
From: =?utf-8?b?TGFycyBHdXN0w6RiZWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?TGFycyBHdXN0w6RiZWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Thu, 21 May 2009 09:18:39 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1242897519.53.0.846078693488.issue6054@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

So, what exactly are trying to accomplish? Why do you need that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From =?utf-8?q?Ugra_D=C3=A1niel_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za  Thu May 21 12:38:01 2009
From: =?utf-8?q?Ugra_D=C3=A1niel_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za (=?utf-8?q?Ugra_D=C3=A1niel_=3Creport=40bugs=2Epython=2Eorg=3E?= at psf.upfronthosting.co.za)
Date: Thu, 21 May 2009 10:38:01 +0000
Subject: [issue6077] Unicode issue with tempfile on Windows
In-Reply-To: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>
Message-ID: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>


New submission from Ugra D?niel <daniel.ugra at gmail.com>:

Opening a file with tempfile.TemporaryFile using "wt+" mode, then
reading content back, will cause reading to stop (without any exception)
when encountering byte '0x1a' (aka. Ctrl+Z) on Windows even tough UTF-16
encoding is used. When using built-in open with the same parameters
(plus a file name of course) everything works as expected. On Linux this
issue does not exists.

----------
components: Library (Lib)
files: UnicodeTest.py
messages: 88151
nosy: daniel.ugra
severity: normal
status: open
title: Unicode issue with tempfile on Windows
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file14032/UnicodeTest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6077>
_______________________________________

From =?utf-8?b?SmVzw7pzIENlYSBBdmnDs24gPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Fri May 22 14:17:17 2009
From: =?utf-8?b?SmVzw7pzIENlYSBBdmnDs24gPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24gPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 12:17:17 +0000
Subject: [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1242994637.79.0.719919851777.issue3541@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I can *not* reproduce the problem with Python 2.6 (with its stock bsddb
version) and Berkeley DB 4.7.25 (the current one).

I can reproduce the issue if I use Berkeley DB 4.6.21. Seems to be a
(solved) problem in the library.

Berkeley DB 4.7.25 is known to solve a few memory leaks:
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/changelog/4.7.html

I mark the bug as "closed" and "out of date" because it is no something
we can solve and it is already resolved in BDB 4.7.25, published a year ago.

Moreover, any serious usage of Berkeley DB "demands" a recent version of
the library.

----------
assignee: jcea -> 
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 21:12:56 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 19:12:56 +0000
Subject: [issue6067] make error
In-Reply-To: <1242810066.3.0.038429040919.issue6067@psf.upfronthosting.co.za>
Message-ID: <4A16F932.7060409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 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

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6067>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 21:15:11 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 19:15:11 +0000
Subject: [issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1243019711.7.0.314575913812.issue6070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to provide a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 21:29:59 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 19:29:59 +0000
Subject: [issue6065] bdist_msi.py failed assert when including extension
	modules
In-Reply-To: <4A1329EC.3020307@timgolden.me.uk>
Message-ID: <1243020599.83.0.517754875956.issue6065@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee: tarek -> loewis
nosy: +loewis
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6065>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 21:38:42 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 19:38:42 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1243021122.2.0.797280147364.issue6071@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

exarkun: would you like to propose a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 21:58:12 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 19:58:12 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <1242966100.94.0.996788852311.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4A1703CE.7010206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The first warning might be a problem.  I understand from the docs
> (http://msdn.microsoft.com/en-us/library/aa363866.aspx) that all I need
> to do is include windows.h, which is already included... but still the
> function prototype isn't present.  This might be because a preprocessor
> declaration of WINVER isn't set high enough... but since the same
> executable is built for all versions of Windows, how is this reconciled
> in the compiler?

Good point. Unfortunately, backwards compatibility requires this to
be hackish. We currently strive for compatibility with Windows 2000,
so we cannot statically reference these functions (unless we increase
the minimum required Windows version - but we surely have to support XP
for many years to come).

So, in essence, you need to GetProcAddress. See other examples in
posixmodule.c for how this is done, and raise an exception
(NotImplementedError? WindowsError with ERROR_CALL_NOT_IMPLEMENTED
?) if you can't find the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 22:14:46 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 20:14:46 +0000
Subject: [issue6083] Reference counting bug in setrlimit
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1243023286.46.0.912591233769.issue6083@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IMO, any refcounting bug has the potential as a security risk. So I
think we should deprecate this with a warning, and eventually remove it,
as billm proposes.

It's probably debatable whether to backport the warning to 2.6 or
earlier; I think we shouldn't, as many applications are probably valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Fri May 22 22:14:53 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Fri, 22 May 2009 20:14:53 +0000
Subject: [issue6083] Reference counting bug in setrlimit
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1243023293.97.0.837493364028.issue6083@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May 23 12:44:37 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 23 May 2009 10:44:37 +0000
Subject: [issue6093] Ambiguous locale.strxfrm
In-Reply-To: <1243068525.81.0.468614425869.issue6093@psf.upfronthosting.co.za>
Message-ID: <1243075477.89.0.891544914962.issue6093@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. Fixed in r72844 and r72845

----------
nosy: +loewis
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6093>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May 23 13:11:48 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 23 May 2009 11:11:48 +0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1243077108.91.0.805268591748.issue1983@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine to me, please apply.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
_______________________________________

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Sat May 23 13:21:42 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Sat, 23 May 2009 11:21:42 +0000
Subject: [issue6060] PYTHONHOME should be more flexible (and controllable by
	--libdir)
In-Reply-To: <1242712344.32.0.862299052402.issue6060@psf.upfronthosting.co.za>
Message-ID: <1243077702.15.0.766937226827.issue6060@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> PYTHONHOME should point to the Python installation root, period.

And indeed, it does. After your proposed, changed, it wouldn't anymore.
The Python installation root is *not* the directory where the Python
library lives, but the parent directory in which both to find the python
executable (bin/python), and the library (lib/pythonX.Y).

As R. David Murray explains, there is no chance that this definition
could possibly change - it would break existing systems.

I'm not quite sure what you want to achieve: if you want an additional
directory to show up in sys.path, just edit Modules/Setup.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6060>
_______________________________________

From =?utf-8?b?TGFycyBHdXN0w6RiZWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Sat May 23 14:03:20 2009
From: =?utf-8?b?TGFycyBHdXN0w6RiZWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?TGFycyBHdXN0w6RiZWwgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Sat, 23 May 2009 12:03:20 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1243080200.96.0.764129930824.issue6054@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Apparently, the .deb file format is not explicit about that, but it
seems to be common practice to have all files prefixed with './'.

normpath is used all over tarfile, crucial are the occurrences in
TarFile.add() and TarInfo.get_info(). As you're using a unix-like system
the easiest workaround is to replace the module level tarfile.normpath
function with a no-op.

The original assumption for using normpath on all pathnames was to keep
the names in an archive clean and in their canonical form. Most
occurrences of normpath date back to the 2003 original version (cp.
r30613) and have never been touched.

But, I found nothing in POSIX about normalizing pathnames. GNU tar and
star both strip different leading path components like "./" and "../"
from pathnames, but they both don't remove "./" components from inside a
pathname, for example. This means that the usage of normpath seems more
or less unnecessary in tarfile.

I will create a patch that addresses these issues.

Thanks for your report.

----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From rdmurray at bitdance.com  Tue May 19 19:11:41 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 19 May 2009 13:11:41 -0400 (EDT)
Subject: [issue1309352] Make fcntl work properly on AMD64
In-Reply-To: <1242750267.06.0.131792045179.issue1309352@psf.upfronthosting.co.za>
References: <1242750267.06.0.131792045179.issue1309352@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0905191310440.3802@kimball.webabinitio.net>

On Tue, 19 May 2009 at 16:24, Antoine Pitrou wrote:
> Thanks! For the record, did the rest of test_fcntl pass?
> Is it a 32-bit or a 64-bit build?

Yes and 32 bit.

From orsenthil at gmail.com  Wed May 20 17:06:48 2009
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 20 May 2009 10:06:48 -0500
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <20090520150648.GC16205@ubuntu.ubuntu-domain>

> Facundo Batista <facundo at taniquetil.com.ar> added the comment:
> 
> Hans, please take a look to my comment 79573 in this same bug. If you
> could do that, it'd be amazing...


Oops, had missed that one.. Shall update the patch, Facundo.

From report at bugs.python.org  Tue May 26 16:48:50 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 14:48:50 +0000
Subject: [issue6109] IDLE rendering issue with oriental characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243349330.03.0.832836180792.issue6109@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached file is an example of text that works fine in Textmate but 
renders incorrectly in IDLE.

----------
Added file: http://bugs.python.org/file14079/Chinese.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6109>
_______________________________________

From report at bugs.python.org  Tue May 26 17:01:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 15:01:30 +0000
Subject: [issue6109] IDLE rendering issue with oriental characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243350090.47.0.718005623358.issue6109@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is definitly an Tk issue, the issue seems to be fixed in Tcl/Tk 8.5.

That is, when I install Tk 8.5 and rerun the Tcl scriptlet I posted 
earlier the problem goes away. I'm currently rebuilding a version of the 
tkinter extension that links to Tk 8.5 to check if that solves the problem 
in IDLE as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6109>
_______________________________________

From report at bugs.python.org  Tue May 26 17:13:33 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 15:13:33 +0000
Subject: [issue6109] IDLE rendering issue with oriental characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243350813.15.0.699141581419.issue6109@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Switching to Tcl/Tk 8.5 fixes the issue for IDLE as well.

I'm leaving this bug open for future reference, and because this affects 
the binary installer for python.

The big question: how to fix this in Python itself. I see the following 
options:

1) Ignore the issue

2) Include Tcl/Tk 8.5 in the OSX installer

   I'm not to happy about this because this would bloat the OSX 
   installer even more and would probably not what heavy Tkinter users
   would like anyway.

3) Add 2 versions of Tkinter.so to the installer: one linked to 
   Tcl 8.4 the other to Tcl 8.5, and automaticly load the right one
   when someone imports Tkinter.

   Then document that users should install a 3th-party Tk 8.5 to fix
   unicode issues.

4) Require Tk 8.5 on the users system.

   This last option is IMHO not acceptable, for better or worse IDLE
   is the most visible bit of the Python installation for new users and
   that should therefore work out of the box.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6109>
_______________________________________

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: [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: [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:14:21 2009
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 26 May 2009 16:14:21 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1243354461.31.0.783129577853.issue1712522@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

The issue of urllib.quote was discussed at extreme length in issue 3300,
which was specific to Python 3.
http://bugs.python.org/issue3300

In the end, I rewrote the entire family of urllib.quote and unquote
functions; they're now Unicode compliant and accept additional encoding
and errors arguments to handle this.

They were never backported to the 2.x branch; maybe we should do so.
Note that the code is quite different and considerably more complex due
to all the new issues with Unicode strings.

----------
nosy: +mgiuca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1712522>
_______________________________________

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: [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 18:15:33 2009
From: report at bugs.python.org (Marco)
Date: Tue, 26 May 2009 16:15:33 +0000
Subject: [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: <1243354533.03.0.00689612483437.issue6074@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

Which version are you using?

I've seen the source code of import.c (2.5 and 2.6) and it seems that in
the 2.6 some bugfixes/features have been added.

However, I've just used the version 2.7 and it works fine (as 2.6, since
they have the same code (at least in import.c), until now).

bye

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Tue May 26 18:22:42 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 16:22:42 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243354962.53.0.92816175135.issue6111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The same problem is also present in IDLE 3.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 18:24:00 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 16:24:00 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243355040.07.0.414639282616.issue6111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Wrt. the question about tracebacks, I get the following exception when I 
click on the Apply button:

 /Applications/Python\ 3.1/IDLE.app/Contents/MacOS/IDLE
Exception in Tkinter callback
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter
/__init__.py", line 1399, in __call__
    return self.func(*args)
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/configDialog.py", line 1129, in Apply
    self.DeactivateCurrentConfig()
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib
/configDialog.py", line 1107, in DeactivateCurrentConfig
    winInstances = self.parent.instance_dict.keys()
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter
/__init__.py", line 1708, in __getattr__
    return getattr(self.tk, attr)
AttributeError: 'tkapp' object has no attribute 'instance_dict'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 18:39:42 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 May 2009 16:39:42 +0000
Subject: [issue6117] Fix O(n**2) performance problem in socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1243355982.0.0.654663495948.issue6117@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good to me.
Be careful for the 3.0 port: filter() returns an iterator.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6117>
_______________________________________

From report at bugs.python.org  Tue May 26 18:43:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 May 2009 16:43:24 +0000
Subject: [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: <1243356204.67.0.936657358564.issue6115@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r72941.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6115>
_______________________________________

From report at bugs.python.org  Tue May 26 18:44:42 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 26 May 2009 16:44:42 +0000
Subject: [issue6117] Fix O(n**2) performance problem in socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1243356282.31.0.0970210748927.issue6117@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

the filter() is rendundant, really.  There is no reason to drop those 
empty strings at this stage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6117>
_______________________________________

From report at bugs.python.org  Tue May 26 18:50:15 2009
From: report at bugs.python.org (Trent Mick)
Date: Tue, 26 May 2009 16:50:15 +0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
	(same with context_diff)
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1243356615.71.0.519990672554.issue2142@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

Here is a new patch that also fixes the same issue in
difflib.context_diff() and adds a couple test cases.

----------
stage: test needed -> patch review
title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char -> naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff)
Added file: http://bugs.python.org/file14082/python_difflib_no_eol.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Tue May 26 18:55:20 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 26 May 2009 16:55:20 +0000
Subject: [issue5794] pickle/cPickle of recursive tuples create pickles that
	cPickle can't load
In-Reply-To: <1240170780.68.0.204813353535.issue5794@psf.upfronthosting.co.za>
Message-ID: <1243356920.48.0.580310500292.issue5794@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Fixed in r72930 (trunk), r72931 (2.6), r72942 (py3k).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5794>
_______________________________________

From report at bugs.python.org  Tue May 26 19:46:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 26 May 2009 17:46:57 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1243360017.39.0.607368089183.issue4859@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> loewis
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Tue May 26 19:58:33 2009
From: report at bugs.python.org (Alex James)
Date: Tue, 26 May 2009 17:58:33 +0000
Subject: [issue6107] Subprocess.Popen output fails on Windows
In-Reply-To: <1243298755.35.0.185322237377.issue6107@psf.upfronthosting.co.za>
Message-ID: <1243360713.77.0.635759529578.issue6107@psf.upfronthosting.co.za>


Alex James <ac.james at shaw.ca> added the comment:

>>> import subprocess
>>> fileName = 'test_a5.py.out'
>>> locator = 'step 5200 '
>>> p = subprocess.Popen('findstr /O /B /C:"' + locator + '" '+
fileName, stdout=subprocess.PIPE, shell=True)
>>> print p.stdout.read()

>>> print p.communicate()[0]

And stderr is also returning None when similarly referenced.  I'm using
relative file paths since the script and data files are all kept in the
same directory, and to avoid escaping backslashes.  
When the same (composited) line is typed into cmd.exe it returns properly
223473:step 5200 potentialEnergySum -2643.62601773

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6107>
_______________________________________

From report at bugs.python.org  Tue May 26 20:28:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 May 2009 18:28:22 +0000
Subject: [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: <1243362502.95.0.96241385714.issue6116@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6116>
_______________________________________

From report at bugs.python.org  Tue May 26 20:31:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 May 2009 18:31:32 +0000
Subject: [issue6118] urllib.parse.quote_plus ignores optional arguments
In-Reply-To: <1243354524.61.0.291164440748.issue6118@psf.upfronthosting.co.za>
Message-ID: <1243362692.8.0.405817703256.issue6118@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r72943.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6118>
_______________________________________

From report at bugs.python.org  Tue May 26 20:36:59 2009
From: report at bugs.python.org (Alex James)
Date: Tue, 26 May 2009 18:36:59 +0000
Subject: [issue6107] Subprocess.Popen output fails on Windows
In-Reply-To: <1243298755.35.0.185322237377.issue6107@psf.upfronthosting.co.za>
Message-ID: <1243363019.61.0.0154296618861.issue6107@psf.upfronthosting.co.za>


Alex James <ac.james at shaw.ca> added the comment:

Um, nevermind.  
I completely missed cwd=os.path.split(sys.argv[0])[0] so the shell
command wasn't operating in the same relative path as the script.  

And that never mattered on Unix because we always ran from commandline,
not IDLE, so the shell inherited the commandline directory where we ran
the script.  

Now don't I feel silly for spending three days on this.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6107>
_______________________________________

From report at bugs.python.org  Tue May 26 20:41:48 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 18:41:48 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243363308.76.0.304374938117.issue6111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The fact that it seems to work on the trunk is accidental, another bug 
causes the code to go into a branch for a "old" version of Tk even when 
running on a newer one. The code in the "new" branch triggers the bug.

I've committed a fix in r72945, although I'm not too happy about the 
patch. I haven't got a clue on how to fix this in a cleaner way.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 20:42:12 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 May 2009 18:42:12 +0000
Subject: [issue6111] Impossible to change preferences in IDLE
In-Reply-To: <1243320883.94.0.150979154921.issue6111@psf.upfronthosting.co.za>
Message-ID: <1243363332.09.0.468780256584.issue6111@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Removing the newer 8.4 /Library/Frameworks/Tcl.framework/ at runtime makes 
the problem go away.  (Also the official 3.0.1 python wasn't linked with 
the newer Tcl in place so it doesn't exhibit these symptoms).

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6111>
_______________________________________

From report at bugs.python.org  Tue May 26 20:46:01 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 May 2009 18:46:01 +0000
Subject: [issue6110] IDLE has two "Preferences..." menu's on OSX
In-Reply-To: <1243320712.83.0.629462070436.issue6110@psf.upfronthosting.co.za>
Message-ID: <1243363561.92.0.427685105736.issue6110@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Apparently, also caused by using the newer Tcl 8.4 in 
/Library/Frameworks/Tcl.

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6110>
_______________________________________

From report at bugs.python.org  Tue May 26 20:48:26 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 18:48:26 +0000
Subject: [issue6110] IDLE has two "Preferences..." menu's on OSX
In-Reply-To: <1243320712.83.0.629462070436.issue6110@psf.upfronthosting.co.za>
Message-ID: <1243363706.94.0.0793232410296.issue6110@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This was caused by code in macosxSupport.py that picked the branch for
the wrong Tk release because "[8, 4, 21] < (8, 4, 21)". 

Committed a fix in r72946

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6110>
_______________________________________

From report at bugs.python.org  Tue May 26 20:50:05 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 18:50:05 +0000
Subject: [issue6110] IDLE has two "Preferences..." menu's on OSX
In-Reply-To: <1243320712.83.0.629462070436.issue6110@psf.upfronthosting.co.za>
Message-ID: <1243363805.05.0.295088497151.issue6110@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Supporting multiple versions of Tk sucks, and that's without trying to
support Tk 8.5 as well (at least not in the binary installers)

Appearently support for the Cocoa port of Tk requires even more
specialcasing...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6110>
_______________________________________

From report at bugs.python.org  Tue May 26 21:00:04 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 19:00:04 +0000
Subject: [issue5653] OS X Installer: by default install versioned-only links
	in /usr/local/bin for 3.x
In-Reply-To: <1238604776.11.0.0788260895322.issue5653@psf.upfronthosting.co.za>
Message-ID: <1243364404.14.0.753066025099.issue5653@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Good point, especially because the file in /usr/local/bin seem to be how a 
lot of users still use the framework.

I'm committing a patch later today (which will include properly installing 
2to3 in a framework build)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5653>
_______________________________________

From report at bugs.python.org  Tue May 26 21:03:44 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 26 May 2009 19:03:44 +0000
Subject: [issue1064] Test issue
In-Reply-To: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za>
Message-ID: <1243364624.11.0.568771506184.issue1064@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Testing a bug: does mentioning version 123123123123 or issue
123123123123 make this issue unable to be displayed?

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1064>
_______________________________________

From report at bugs.python.org  Tue May 26 21:10:03 2009
From: report at bugs.python.org (Daniel's Test)
Date: Tue, 26 May 2009 19:10:03 +0000
Subject: [issue1064] Test issue
In-Reply-To: <1243364624.11.0.568771506184.issue1064@psf.upfronthosting.co.za>
Message-ID: <2d75d7660905261209n574e68c3n7f83dc685149dacb@mail.gmail.com>


Daniel's Test <ajaksu at gmail.com> added the comment:

> Testing a bug: does mentioning version 123123123123 or issue
> 123123123123 make this issue unable to be displayed?

Yes, it does :(

See http://psf.upfronthosting.co.za/roundup/meta/issue285 for a patch
that contains the fix.

----------
nosy: +dtuser2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1064>
_______________________________________

From report at bugs.python.org  Tue May 26 21:47:06 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Tue, 26 May 2009 19:47:06 +0000
Subject: [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: <1243367226.93.0.0932337161956.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

Oops, I was not accurate in reporting behavior: I now believe that this fails on Windows XP, but may work 
fine on Linux. Below are my results, showing reproducible failure on XP. The most important thing about 
this is: on XP, once the .pyc file is "broken", Python will not overwrite it, and it must be *manually* 
removed. This is bad!

I will append Ubuntu results in a few minutes.

To reproduce the problem, I had to modify the script to include a "sleep", see attached 
showpyreadonlysleep.sh (cygwin bash script).

Here's the results of running showpyreadonlysleep.sh, then manually reproducing the problem with 
"touch/python":

$ ./showpycreadonlysleep.sh
umask = 0022
CYGWIN_NT-5.1 psimanyi_xp 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
Python 2.6.2
Running python.exe from: /cygdrive/c/Python26/python
-rw-r--r-- 1 psimanyi mkgroup-l-d 10 May 26 12:43 b.py
b
-rwx------+ 1 psimanyi mkgroup-l-d 137 May 26 12:43 b.pyc
b
-r-x------+ 1 psimanyi mkgroup-l-d 137 May 26 12:43 b.pyc
# c:\Documents and Settings\psimanyi\b.pyc has bad mtime
import b # from c:\Documents and Settings\psimanyi\b.py
# can't create c:\Documents and Settings\psimanyi\b.pyc

And now, running manually:


$ touch b.py

psimanyi at psimanyi_xp ~
$ python -v a.py 2>&1 | grep 'b\.py'
# c:\Documents and Settings\psimanyi\b.pyc has bad mtime
import b # from c:\Documents and Settings\psimanyi\b.py
# can't create c:\Documents and Settings\psimanyi\b.pyc

psimanyi at psimanyi_xp ~
$ touch b.py

psimanyi at psimanyi_xp ~
$ python -v a.py 2>&1 | grep 'b\.py'
# c:\Documents and Settings\psimanyi\b.pyc has bad mtime
import b # from c:\Documents and Settings\psimanyi\b.py
# can't create c:\Documents and Settings\psimanyi\b.pyc

Again, this shows that without removing the .pyc manually, the pyc will not be overwritten, and therefore 
program startup will be slow!

----------
Added file: http://bugs.python.org/file14083/showpycreadonlysleep.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Tue May 26 21:57:45 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Tue, 26 May 2009 19:57:45 +0000
Subject: [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: <1243367865.43.0.58572683984.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

Re: Ubuntu: I can't reproduce the problem. At this point, I consider this problem Windows XP-only.

Re: Windows & bash: I decided to verify that this problem occurs even if running outside of Bash in 
the native (and wonderful) shell CMD.EXE. It *does* occur. Here's the state:

[1] Run my script in Bash, which fails as in my previous append from today.
[2] Start CMD.EXE. Then run a "touch b.py" in Bash, then verify using Bash "ls -l" that b.py is 
protection 444 (readonly).
[3] In CMD.EXE, run "python -v a.py" (I don't know how to use something like grep in CMD.EXE, so I 
just manually copy/pasted the "python -v" lines.) The following lines in CMD.EXE's output show that 
the problem still occurs in CMD.EXE:

# C:\Documents and Settings\psimanyi\b.pyc has bad mtime
import b # from C:\Documents and Settings\psimanyi\b.py
# can't create C:\Documents and Settings\psimanyi\b.pyc
b
# clear __builtin__._


If you are unable to reproduce this on XP, I will be happy to help.

I would not be surprised if this had something to do with the granularity of mtime or some other 
oddity of Windows, because: if I delete the sleep in the Bash script, then rerun the Bash script very 
quickly using "control-P control-J" typed ahead, sometimes the Bash script fails and sometimes it 
succeeds! (Nice work, Windows.)

Thanks much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Tue May 26 22:41:26 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Tue, 26 May 2009 20:41:26 +0000
Subject: [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: <1243370486.97.0.813702509756.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

I may have a reason to analyze that would explain why this fails on 
Windows: the non-Windows code path in import.c's open_exclusive() contians 
an unlink(filename), but the Windows path does not.

I'm going to try to build Python on Windows and add an unlink for both 
code paths.

More later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Tue May 26 23:19:40 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 21:19:40 +0000
Subject: [issue5653] OS X Installer: by default install versioned-only links
	in /usr/local/bin for 3.x
In-Reply-To: <1238604776.11.0.0788260895322.issue5653@psf.upfronthosting.co.za>
Message-ID: <1243372780.38.0.725471994659.issue5653@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Checked in a fix for this in r72947.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5653>
_______________________________________

From report at bugs.python.org  Tue May 26 23:19:53 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 21:19:53 +0000
Subject: [issue5653] OS X Installer: by default install versioned-only links
	in /usr/local/bin for 3.x
In-Reply-To: <1238604776.11.0.0788260895322.issue5653@psf.upfronthosting.co.za>
Message-ID: <1243372793.65.0.82411228107.issue5653@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5653>
_______________________________________

From report at bugs.python.org  Tue May 26 23:22:20 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 21:22:20 +0000
Subject: [issue5272] OS X installer: fix makefile target changed for 3.x
In-Reply-To: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
Message-ID: <1243372940.55.0.651322364293.issue5272@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

You've got a point there.

Benjamin: should the removal of smtpd.py from the list of installed 
scripts be listed in the NEWS file?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________

From report at bugs.python.org  Tue May 26 23:23:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 May 2009 21:23:13 +0000
Subject: [issue5272] OS X installer: fix makefile target changed for 3.x
In-Reply-To: <1243372940.55.0.651322364293.issue5272@psf.upfronthosting.co.za>
Message-ID: <1afaf6160905261423o44da82d0jf87bab7e31ad269d@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/5/26 Ronald Oussoren <report at bugs.python.org>:
>
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> You've got a point there.
>
> Benjamin: should the removal of smtpd.py from the list of installed
> scripts be listed in the NEWS file?

Yes, do you want to do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________

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: [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  Tue May 26 23:24:59 2009
From: report at bugs.python.org (Alejandro)
Date: Tue, 26 May 2009 21:24:59 +0000
Subject: [issue6119] Confusing DeprecationWarning
In-Reply-To: <1243373041.06.0.391551220918.issue6119@psf.upfronthosting.co.za>
Message-ID: <1243373099.8.0.905839997437.issue6119@psf.upfronthosting.co.za>


Changes by Alejandro <alejolp at alejolp.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6119>
_______________________________________

From report at bugs.python.org  Tue May 26 23:39:34 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 26 May 2009 21:39:34 +0000
Subject: [issue5272] OS X installer: fix makefile target changed for 3.x
In-Reply-To: <1234688914.68.0.888662727097.issue5272@psf.upfronthosting.co.za>
Message-ID: <1243373974.18.0.572070875668.issue5272@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Sure. Done in r72948.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5272>
_______________________________________

From report at bugs.python.org  Tue May 26 23:40:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 May 2009 21:40:27 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243374027.89.0.710762939889.issue6105@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Skip, the json API for 2.7/3.1 includes an object_pairs_hook that allows
an OrderedDict to be generated from a json file.  The OP is pointing out
that the latest C upgrade prevents round-tripping while preserving
order.  Use cases for that were discussed in the thread for the
object_pairs_hook.  While you can't count on order preservation on both
ends, there are tools such as PHP that do preserve order.  Also, when
working with manually type user inputs (such as config files), it is
nice when updates generally keep the file in its original order so that
it is clear what had changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Wed May 27 00:17:25 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Tue, 26 May 2009 22:17:25 +0000
Subject: [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: <1243376245.35.0.656664136236.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

I have a fix for this. The code is Windows-only. It has been verified to work for attached test script 
showpycreadonlysleep.sh. It simply adds a "chmod" call. The issue is that the unlink() call silently fails 
if the file is readonly, but unlink() succeeds if chmod() makes the file writable.

Out company would really appreciate having this fix integrated into 2.6 since we use the ActiveState 2.6 
builds on Windows. I haven't test this on non-Windows platforms but it should not change the behavior on 
non-Windows platforms if the #ifdef MS_WINDOWS is correct. The diff is below:

$ svn diff
Index: import.c
===================================================================
--- import.c    (revision 72946)
+++ import.c    (working copy)
@@ -840,6 +840,7 @@
 static FILE *
 open_exclusive(char *filename, mode_t mode)
 {
+
 #if defined(O_EXCL)&&defined(O_CREAT)&&defined(O_WRONLY)&&defined(O_TRUNC)
        /* Use O_EXCL to avoid a race condition when another process tries to
           write the same file.  When that happens, our open() call fails,
@@ -848,6 +849,9 @@
           writable, the file will never be written.  Oh well.
        */
        int fd;
+#ifdef MS_WINDOWS
+        (void) chmod(filename, 0600);
+#endif
        (void) unlink(filename);
        fd = open(filename, O_EXCL|O_CREAT|O_WRONLY|O_TRUNC
 #ifdef O_BINARY


It may be appropriate to document that the chmod() is only required on Windows, and therefore it is only 
called on Windows to avoid slowing down non-Windows platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Wed May 27 00:40:27 2009
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 26 May 2009 22:40:27 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1243377627.3.0.0933279508758.issue6106@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Try using telnetlib.py from python3.1.  It fixes issues in telnet out of
band negotiations.  

http://svn.python.org/projects/python/branches/py3k/Lib/telnetlib.py

Here is what I think is happening:
HOST: b'User' + IAC + ECHO + DONT + b'name:\nPassword\n:'
read_until: times out on Username match, returns all HOST text so far.
You: *send username*
HOST: >
read_until: times out on Password match, returns '>'
You: *send password*
read_until: times out on '>' match, returns ''

This is the only way I could repeat the problem using a local Echo server.

Please let me know if using the telnetlib.py from 3.1 works for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Wed May 27 00:40:53 2009
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 26 May 2009 22:40:53 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1243377653.31.0.737713702415.issue6106@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Wed May 27 01:07:55 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Tue, 26 May 2009 23:07:55 +0000
Subject: [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: <1243379275.87.0.257882159527.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

I realized that my patch, with a chmod(..., 0600), may not work under 
certain conditions where the original file is owned by a different user 
but the directory is group- or world-writable. A more likely correct fix 
would use chmod(..., 0666).

At any rate: someone should test the various combinations of whether this 
user or another user owns the original .pyc file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Wed May 27 06:19:52 2009
From: report at bugs.python.org (Wentao Han)
Date: Wed, 27 May 2009 04:19:52 +0000
Subject: [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:42 2009
From: report at bugs.python.org (July)
Date: Wed, 27 May 2009 04:57:42 +0000
Subject: [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 07:01:42 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 27 May 2009 05:01:42 +0000
Subject: [issue6120] zipfile.ZipFile's extractall works inproperly under
	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243400502.3.0.522171884517.issue6120@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I cannot reproduce this. Can you upload problematic zip file?

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6120>
_______________________________________

From report at bugs.python.org  Wed May 27 07:48:27 2009
From: report at bugs.python.org (Marco)
Date: Wed, 27 May 2009 05:48:27 +0000
Subject: [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: <1243403307.14.0.544317746237.issue6074@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

TO pdsimanyi:

chmod it's not appropriate to change the permissions as you made: 0666
et voil?.

However, I don't understand if it can be a problem since you're using
Cygwin (and Bash under Windows) or not. I think this because Windows is
not POSIX compliant and under Windows the permissions are different than
the others under *NIX-like platforms (POSIX compliant).

Maybe in these days I can check the permissions on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Wed May 27 08:01:15 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 27 May 2009 06:01:15 +0000
Subject: [issue6121] help('modules ') causes IndexError.
Message-ID: <1243404075.0.0.87579111681.issue6121@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
assignee: theller -> 
components:  -ctypes
nosy:  -theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6121>
_______________________________________

From report at bugs.python.org  Wed May 27 08:04:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 May 2009 06:04:30 +0000
Subject: [issue6121] help('modules ') causes IndexError.
In-Reply-To: <1243404269.54.0.906721483587.issue6121@psf.upfronthosting.co.za>
Message-ID: <1243404269.54.0.906721483587.issue6121@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Here is a trivial patch for pydoc with a minimal test.

----------
components: +Library (Lib)
keywords: +easy, patch
nosy: +r.david.murray
priority:  -> low
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14085/issue6121.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6121>
_______________________________________

From report at bugs.python.org  Wed May 27 08:53:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 May 2009 06:53:02 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1243407182.64.0.641976339492.issue6105@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r72961 Fixed for Py3.1.  Leaving open until backported to 2.7.

----------
priority: critical -> normal
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Wed May 27 10:09:58 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 08:09:58 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243411798.99.0.102930089691.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

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

Example library and main program are attached.

----------
nosy: +yonas
Added file: http://bugs.python.org/file14086/mylib.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Wed May 27 10:10:28 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 08:10:28 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243411828.34.0.834766726688.issue1731717@psf.upfronthosting.co.za>


Changes by Yonas <yonas.y at gmail.com>:


Added file: http://bugs.python.org/file14087/main.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

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: [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 10:12:25 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 08:12:25 +0000
Subject: [issue6122] [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243411945.86.0.0848068695746.issue6122@psf.upfronthosting.co.za>


Changes by Yonas <yonas.y at gmail.com>:


Added file: http://bugs.python.org/file14089/main.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 10:13:00 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 08:13:00 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243411980.25.0.404367471101.issue6122@psf.upfronthosting.co.za>


Changes by Yonas <yonas.y at gmail.com>:


----------
title: [Errno 10] No child processes -> OSError: [Errno 10] No child processes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 10:13:32 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 08:13:32 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243412012.14.0.901106824097.issue6122@psf.upfronthosting.co.za>


Changes by Yonas <yonas.y at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 10:36:59 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 May 2009 08:36:59 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243413419.85.0.551385612555.issue6122@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The content of exim_local_scan2.py would be useful as well.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 12:54:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 10:54:39 +0000
Subject: [issue6120] zipfile.ZipFile's extractall works inproperly under
	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243421679.93.0.27973121333.issue6120@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file14090/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6120>
_______________________________________

From report at bugs.python.org  Wed May 27 12:57:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 10:57:30 +0000
Subject: [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: <1243421850.88.0.722085010156.issue6102@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you test with the 3.1 beta? There's a Windows installer here:
http://python.org/download/releases/3.1/

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6102>
_______________________________________

From report at bugs.python.org  Wed May 27 13:23:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 May 2009 11:23:52 +0000
Subject: [issue6077] Unicode issue with tempfile on Windows
In-Reply-To: <1242902281.19.0.785534921176.issue6077@psf.upfronthosting.co.za>
Message-ID: <1243423432.57.0.65900318374.issue6077@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

File descriptors wrapped by the new IO module should be opened in binary
mode.

The attached patch changes TemporaryFile and NamedTemporaryFile to
always call os.open() in binary mode; the mode is really used by the
io.open() function.

mkstemp() returns a raw file descriptor and was not changed.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14092/tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6077>
_______________________________________

From report at bugs.python.org  Wed May 27 13:29:31 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 27 May 2009 11:29:31 +0000
Subject: [issue6120] zipfile.ZipFile's extractall works inproperly under
	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243423771.43.0.0153570699923.issue6120@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I confirmed error happened on Python2.6, 2.7, 3.0.
But not happen on Python3.1. Interesting.

----------
versions: +Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6120>
_______________________________________

From report at bugs.python.org  Wed May 27 13:31:19 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 27 May 2009 11:31:19 +0000
Subject: [issue6120] zipfile.ZipFile's extractall works inproperly under
	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243423879.82.0.283391221495.issue6120@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is traceback for trunk(Py2.7)

Traceback (most recent call last):
  File "b.py", line 3, in <module>
    f.extractall()
  File "e:\python-dev\trunk\lib\zipfile.py", line 947, in extractall
    self.extract(zipinfo, path, pwd)
  File "e:\python-dev\trunk\lib\zipfile.py", line 935, in extract
    return self._extract_member(member, path, pwd)
  File "e:\python-dev\trunk\lib\zipfile.py", line 974, in _extract_member
    os.mkdir(targetpath)
WindowsError: [Error 183] ??????????????????????
??: 'E:\
\temp\\b'

# Error message says "Cannot create the file which already exists"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6120>
_______________________________________

From report at bugs.python.org  Wed May 27 13:33:57 2009
From: report at bugs.python.org (Suzumizaki)
Date: Wed, 27 May 2009 11:33:57 +0000
Subject: [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: <1243424037.99.0.103599304348.issue6102@psf.upfronthosting.co.za>


Suzumizaki <suzumizaki at free.japandesign.ne.jp> added the comment:

Thanks for reply.

I tried Python 3.1 Beta, and the testcode goes fine.
(and my current work also.) 

I checked with Windows XP, I told before.
My problem seems resolved, and here is answers only to make sure.

>(What is the value of sys.maxunicode there though?)

65535.

> I ran the script from the terminal with "python3 test.py" twice and it
> worked both the time (is this the correct way to use the script?).

Yes.

> If you delete the .pyc an reload the script again, does it work?

You mean "and" insted of "an", right?
The answer is Yes, even Python 3.0.1.

> (Next time upload the files separately, it's easier for us to see them.)

OK, I know.

Thank you very much for all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6102>
_______________________________________

From report at bugs.python.org  Wed May 27 13:35:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 May 2009 11:35:37 +0000
Subject: [issue6120] zipfile.ZipFile's extractall works inproperly under
	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243424137.06.0.838638810899.issue6120@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think this was fixed by r72893:
  Issue #6050: Don't fail extracting a directory from a zipfile if
  the directory already exists.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6120>
_______________________________________

From report at bugs.python.org  Wed May 27 14:27:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 May 2009 12:27:11 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243427231.65.0.243560693489.issue6122@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Library (Lib)
type: crash -> behavior

_______________________________________
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: [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 14:29:21 2009
From: report at bugs.python.org (Evan Jones)
Date: Wed, 27 May 2009 12:29:21 +0000
Subject: [issue6123] tarfile: opening an empty tar file fails
In-Reply-To: <1243427347.79.0.845990376951.issue6123@psf.upfronthosting.co.za>
Message-ID: <1243427361.15.0.268256087391.issue6123@psf.upfronthosting.co.za>


Changes by Evan Jones <evanj at mit.edu>:


----------
title: tarfile: -> tarfile: opening an empty tar file fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6123>
_______________________________________

From report at bugs.python.org  Wed May 27 14:37:11 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 27 May 2009 12:37:11 +0000
Subject: [issue6120] zipfile.ZipFile's extractall works inproperly under
	Windows
In-Reply-To: <1243397989.45.0.455462887629.issue6120@psf.upfronthosting.co.za>
Message-ID: <1243427831.9.0.978367218842.issue6120@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oops, sorry. I forgot to update working copy. I confirmed this was fixed
already.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6120>
_______________________________________

From report at bugs.python.org  Wed May 27 16:00:40 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 May 2009 14:00:40 +0000
Subject: [issue5851] Add a stream parameter to gc.set_debug
In-Reply-To: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
Message-ID: <1243432840.73.0.600953027189.issue5851@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Would you like to work on a patch?

----------
components: +Interpreter Core -Extension Modules
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5851>
_______________________________________

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: [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 17:14:39 2009
From: report at bugs.python.org (Peter Simanyi)
Date: Wed, 27 May 2009 15:14:39 +0000
Subject: [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: <1243437279.44.0.0918088006828.issue6074@psf.upfronthosting.co.za>


Peter Simanyi <psimanyi at namcobandaigames.com> added the comment:

Re: chmod 0666 inappropriate: I agree that leaving a file 0666 is inappropriate, however theoretically 
the code should never leave the file 0666 since the unlink will delete the file.

The code was intended to show what the problem is by demonstrating a solution. Note that the line 
immediately following the chmod 0666 is an unlink call, which will delete the file if the user had 
sufficient permission to chmod the file to 0666.

I suppose the meta-level description of the problem is:
[1] Without the chmod 0666, the unlink will fail if the file is 0400 or similar.
[2] With the chmod 0666, the unlink succeeds, and the file will be recreated with new permissions (not 
0666: I believe my tests show 0444) after the post-unlink file creation.
[3] Someone familiar with windows should analyze, propose a solution, test it under all relevant 
scenarios of file/group ownership (and again the chmod is only required on Windows), and on 
XP/Vista/Win7.

The only problem I can see with the chmod 0666 is if for some reason the file still exists with bad 
permissions after the unlink. Since this is a low-overhead operation compared to the time to regenerate 
the .pyc file, I think that it would be reasonable to have an #ifdef MS_WINDOWS, if the file exists 
after the unlink(), print a big warning message that will always be visible even if -v is not used when 
invoking Python.

This is getting complicated enough that you may want to see if you can get someone else to review it 
for ideas about how to address the chmod/unlink code. I am certainly not a Windows expert hence I'm 
making a best Unix-like attempt to analyze and test fixes.

Good luck and thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Wed May 27 17:31:46 2009
From: report at bugs.python.org (Pal Subbiah)
Date: Wed, 27 May 2009 15:31:46 +0000
Subject: [issue6106] read_until
In-Reply-To: <1243267985.99.0.238483902734.issue6106@psf.upfronthosting.co.za>
Message-ID: <1243438306.59.0.72721551911.issue6106@psf.upfronthosting.co.za>


Pal Subbiah <pal.subbiah at gmail.com> added the comment:

Thanks for your support.
But the telnetlib from 3.1 also behaves in the same way. "read_until" 
always times out and returns b''. The problem seems to be with the byte 
string expected. The string after letter b is not passed properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6106>
_______________________________________

From report at bugs.python.org  Wed May 27 18:50:51 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 16:50:51 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243443051.84.0.985148772575.issue6122@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

The test doesn't fail when run directly from ./main, but it fails when
run from exim4 mail server. 

exim will dlopen() mylib and run local_scan().

Besides using Popen, I haven't had any problems.

----------
Added file: http://bugs.python.org/file14094/exim_local_scan2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 19:28:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 May 2009 17:28:41 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243445321.82.0.55898755568.issue6122@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

your program works for me.
How did you compile the files? I used the following commands:

$ gcc -fPIC -I/usr/local/include/python2.6/ mylib.c -L /usr/local/lib
-lpython2.6 --shared -o mylib.so

$ gcc main.c -ldl 

$ ./a.out
test

(after removing all references to exim4, which is not really used)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 19:44:57 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 17:44:57 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243446297.74.0.931316184305.issue6122@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Thanks for testing, it works when running ./main, but not when run
through exim.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 20:02:55 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 27 May 2009 18:02:55 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1243447375.25.0.0345742512456.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think this would be useful.

I don't fee terribly strongly about it, but I think I'd like the name
str.format_using_mapping(). When I initially saw this, I thought from
the name it was creating a format object (whatever that would be) from a
mapping object.

----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Wed May 27 20:17:42 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 18:17:42 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243448262.88.0.61139771712.issue6122@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

I didn't find anything unusual about how exim uses dlopen, but if you
want to see the code, it's here:

http://pastebin.com/m52398b30

Line 166 is the actual call.

Again, no problems except with Python's Popen().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

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: [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 20:53:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 18:53:56 +0000
Subject: [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: <1243450436.94.0.327022559175.issue6116@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

IMO, any of these three solutions should be accepted.
The second is of course the nicest but also the most complex one, and
it's probably not worth it.
I'm not sure the third solution is easily feasible given that dicts
currently don't accept weakref'ing. We could of course create a special
subclass of dict, but, again, is it worth it?
This leaves us with the first solution which is, IMO, good enough, and
obviously the simplest of all three. You're welcome to propose a patch!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6116>
_______________________________________

From report at bugs.python.org  Wed May 27 20:58:09 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 27 May 2009 18:58:09 +0000
Subject: [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: <1243450689.3.0.922271611899.issue6116@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Oh, I forgot dictionaries aren't weakrefable.  That's such a pain, I
thought the third solution would be a good balance between easy and good. :/

Regarding the first solution, my only question right now is whether this
should be a new attribute/method, or if the behavior of f_locals should
just be changed.  The former would be nicer, I think, and perhaps
f_locals can be deprecated in favor of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6116>
_______________________________________

From report at bugs.python.org  Wed May 27 21:13:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 19:13:36 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1243450689.3.0.922271611899.issue6116@psf.upfronthosting.co.za>
Message-ID: <1243451744.24640.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Regarding the first solution, my only question right now is whether this
> should be a new attribute/method, or if the behavior of f_locals should
> just be changed.  The former would be nicer, I think, and perhaps
> f_locals can be deprecated in favor of it.

I think the behaviour of f_locals can just be changed.
(Other developers may disagree)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6116>
_______________________________________

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: [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 21:22:23 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Wed, 27 May 2009 19:22:23 +0000
Subject: [issue3020] doctest should have lib2to3 integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1243452143.14.0.717961822668.issue3020@psf.upfronthosting.co.za>


Changes by Haoyu Bai <divinekid at gmail.com>:


----------
nosy: +bhy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3020>
_______________________________________

From report at bugs.python.org  Wed May 27 21:34:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 May 2009 19:34:35 +0000
Subject: [issue6121] help('modules ') causes IndexError.
In-Reply-To: <1243404269.54.0.906721483587.issue6121@psf.upfronthosting.co.za>
Message-ID: <1243452875.41.0.765520210454.issue6121@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good, please apply.

----------
assignee:  -> r.david.murray
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6121>
_______________________________________

From report at bugs.python.org  Wed May 27 21:37:20 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 19:37:20 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243453040.82.0.249841248535.issue6122@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Could this be a permissions issue? I have no idea how permissions would
effect it, though...

root at yonas-laptop:/usr/lib/exim4/local_scan# ls -la /usr/sbin/exim4
-rwsr-xr-x 1 root root 824440 2009-02-11 08:53 /usr/sbin/exim4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 21:43:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 19:43:53 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1243453433.66.0.466769997288.issue6001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would you like to upload your patch to Rietveld?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

From report at bugs.python.org  Wed May 27 21:49:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 19:49:46 +0000
Subject: [issue6073] threading.Timer and gtk.main are not compatible
In-Reply-To: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>
Message-ID: <1243453786.96.0.834618874005.issue6073@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well I'm not a gtk user, but try to do something else than a "print" in
the timer. Perhaps gtk redirects all standard IO or something. It sounds
very strange that threads would stop working when gtk is imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6073>
_______________________________________

From report at bugs.python.org  Wed May 27 21:51:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 27 May 2009 19:51:40 +0000
Subject: [issue6073] threading.Timer and gtk.main are not compatible
In-Reply-To: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>
Message-ID: <1243453900.58.0.620924565571.issue6073@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

pygtk doesn't release the GIL around its internal calls unless you call
threads_init.  So I think this is pretty clearly just a misuse of the
pygtk library.  There's nothing at all Python can do about it.  If an
extension library doesn't release the GIL, no Python code can run
concurrently with it.  In this case, the extension API you've invoked is
the Gtk main loop, which runs until you stop it, usually right before
your gtk app exits.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6073>
_______________________________________

From report at bugs.python.org  Wed May 27 21:53:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 May 2009 19:53:23 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1243454003.11.0.362766451771.issue6003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok. It can certainly go in trunk, as for 3.1 it's up to
Benjamin to decide.
Note: the docs should state that the new argument appeared in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6003>
_______________________________________

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: [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:02:26 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 27 May 2009 20:02:26 +0000
Subject: [issue5265] StringIO can duplicate newlines in universal newlines mode
In-Reply-To: <1234650978.85.0.656093494146.issue5265@psf.upfronthosting.co.za>
Message-ID: <1243454546.4.0.776350028429.issue5265@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've filed the Windows issue as http://bugs.python.org/issue6127

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5265>
_______________________________________

From report at bugs.python.org  Wed May 27 22:03:46 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 27 May 2009 20:03:46 +0000
Subject: [issue6127] Unexpected universal newline behavior (newline
	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1243454626.38.0.982999219231.issue6127@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6127>
_______________________________________

From report at bugs.python.org  Wed May 27 22:06:40 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 20:06:40 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243454800.51.0.204632967106.issue6122@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

os.system() works:

os.system("echo `date` >> /tmp/myfile")

root at yonas-laptop:/usr/lib/exim4/local_scan# cat /tmp/myfile 
Wed May 27 16:04:54 EDT 2009
Wed May 27 16:04:54 EDT 2009

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

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: [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:52:48 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 20:52:48 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243457568.09.0.992903909872.issue6122@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Here's another test, taken from the docs:

http://docs.python.org/library/subprocess.html#subprocess-replacements:

This is slightly better than Popen because the program executes and
shows output, but worse than os.system(), because it still shows the error:

--------------------------
try:
            retcode = call("echo" + " \"hello world\"", shell=True)
            if retcode < 0:
                print >>sys.stderr, "Child was terminated by signal",
-retcode
                print >>sys.stderr, "Child was terminated by signal",
-retcode
            else:
                print >>sys.stderr, "Child returned", retcode
        except OSError, e:
            print >>sys.stderr, "Execution failed:", e


-----------------
hello world
Execution failed: [Errno 10] No child processes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 22:53:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 May 2009 20:53:28 +0000
Subject: [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: <1243457608.68.0.724315569267.issue6125@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm sorry; I don't see why this is a bug. Could you elaborate, please?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6125>
_______________________________________

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: [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 22:59:53 2009
From: report at bugs.python.org (Yonas)
Date: Wed, 27 May 2009 20:59:53 +0000
Subject: [issue6122] OSError: [Errno 10] No child processes
In-Reply-To: <1243411936.0.0.7060416625.issue6122@psf.upfronthosting.co.za>
Message-ID: <1243457993.68.0.816407642575.issue6122@psf.upfronthosting.co.za>


Changes by Yonas <yonas.y at gmail.com>:


----------
versions: +Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6122>
_______________________________________

From report at bugs.python.org  Wed May 27 23:00:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 May 2009 21:00:42 +0000
Subject: [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: <1243458042.31.0.873696624383.issue6129@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Is there also a sub/__init__.py?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6129>
_______________________________________

From report at bugs.python.org  Wed May 27 23:02:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 27 May 2009 21:02:40 +0000
Subject: [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:29:23 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 27 May 2009 21:29:23 +0000
Subject: [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: <1243459763.61.0.678807242331.issue6129@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

Yes, I meant to mention that: the directory sub does contain an
__init__.py with "__all__ = ['s']". I'm attaching a zip of the test
package pkg that contains the sub-package sub.

It wasn't clear to me what "import sub.s" should be converted to. By
analogy with the conversion of "import m" to "from . import m", I had
expected "import sub.s" to be converted "from . import sub.s". However,
that is a syntax error (which I don't understand, actually). What works
is "from sub import s" but that could import from a sub module found
anywhere; it isn't changed to a relative import. I don't see how to
write a relative import of a subpackage's module.

I don't doubt that I am confused about something here, but I've
experimented with many variations and can't get it straightened out.

----------
Added file: http://bugs.python.org/file14095/pkg.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6129>
_______________________________________

From report at bugs.python.org  Wed May 27 23:40:19 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 27 May 2009 21:40:19 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1243460419.17.0.0668617624142.issue6001@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

http://codereview.appspot.com/63157

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

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: [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:01:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 May 2009 22:01:20 +0000
Subject: [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: <1243461680.26.0.545080981546.issue6129@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is a case that 2to3 cannot handle. There is no way to do a relative
import and get the module package.module behavior of absolute import.
2to3 cannot guess how to fix this.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6129>
_______________________________________

From report at bugs.python.org  Thu May 28 00:09:25 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 27 May 2009 22:09:25 +0000
Subject: [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: <1243462165.59.0.50610360656.issue6129@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

Thanks. I sure couldn't find a way!

I encountered this trying to convert someone else's code. There is a
main directory and a subdirectory, both with __init__.py files. The
files in the main directory import each other just by "import
othermodule". 2to3 changed those to "from . import othermodule", which
works. There is a module in the sub-package, say 'm', which files in the
main package want to import, which they were doing by "import
subdirectory.m". I'm glad 2to3 can't figure out what to do and, as per
your explanation, I guess there isn't anyway to make this work. So I
have to ask, though perhaps this isn't the place, how would a module in
a package import a module from a sub-package of that package (where the
sub-package includes the module in its all list). I've tried a lot of
variations and am not doing any better than 2to3 on this. Suggestions?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6129>
_______________________________________

From report at bugs.python.org  Thu May 28 00:09:56 2009
From: report at bugs.python.org (Phillip Sitbon)
Date: Wed, 27 May 2009 22:09:56 +0000
Subject: [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 00:11:13 2009
From: report at bugs.python.org (Phillip Sitbon)
Date: Wed, 27 May 2009 22:11:13 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243462273.29.0.731204938142.issue6132@psf.upfronthosting.co.za>


Changes by Phillip Sitbon <phillip.sitbon+python-dev at gmail.com>:


Added file: http://bugs.python.org/file14097/LockingTest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Thu May 28 00:14:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 May 2009 22:14:18 +0000
Subject: [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: <1243462458.67.0.531532383504.issue6129@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The bug tracker is not really the correct forum for this. [See the
python-porting list.]

You will either have to change the code to use absolute from imports and
change the usage of the module in the code base (I would suggest this),
or hack it like this:

import fullpackage.subpack.mod
subpack = fullpackage.subpack

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6129>
_______________________________________

From report at bugs.python.org  Thu May 28 00:23:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 May 2009 22:23:07 +0000
Subject: [issue6121] help('modules ') causes IndexError.
In-Reply-To: <1243404269.54.0.906721483587.issue6121@psf.upfronthosting.co.za>
Message-ID: <1243462987.06.0.115183659771.issue6121@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied in r72966, r72967 and r72968, r72970.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6121>
_______________________________________

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: [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 01:55:13 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 27 May 2009 23:55:13 +0000
Subject: [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: <1243468513.48.0.897565947926.issue6125@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

I apologize. This example evolved from my attempt to simplify things
from the actual code, and I oversimplified to the point where I misread
the 2to3 results. I thought there was a space after the period for the
modules without the underscores in their name but obviously there
wasn't. In the original results there were a lot of "from . import
modulename" and while experimenting with my examples I carelessly
confused the import of an entire module with the import of a name or *
from a module. Sorry for the bother. (There really was a problem with
the code that read "from .modulename import *", but of course it wasn't
that a space was missing after the period.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6125>
_______________________________________

From report at bugs.python.org  Thu May 28 02:02:09 2009
From: report at bugs.python.org (Ben Anhalt)
Date: Thu, 28 May 2009 00:02:09 +0000
Subject: [issue1564508] RFC 2965 BaseCookie does not support "$Port"
Message-ID: <1243468929.05.0.954074864586.issue1564508@psf.upfronthosting.co.za>


Ben Anhalt <ben.anhalt at gmail.com> added the comment:

Actually, I was just bit by this. In fact, RFC 2965 prohibits clients
from sending $Port if the port attribute was not included in the
Set-Cookie header.  But, it turns out that the mono System.Net library
(at least) will add the attribute any time the URI includes a
non-default port number. See http://go-mono.com/forums/#nabble-f1367  I
think this is technically their bug, but it might be nice to have
something like a non-strict mode in Cookie.py that would ignore
unexpected attributes for handling cases like this.

----------
nosy: +benanhalt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1564508>
_______________________________________

From report at bugs.python.org  Thu May 28 02:03:06 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 28 May 2009 00:03:06 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243468986.65.0.30007188224.issue6132@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Thu May 28 02:05:46 2009
From: report at bugs.python.org (Ben Anhalt)
Date: Thu, 28 May 2009 00:05:46 +0000
Subject: [issue1564508] RFC 2965 BaseCookie does not support "$Port"
Message-ID: <1243469146.66.0.644347346615.issue1564508@psf.upfronthosting.co.za>


Ben Anhalt <ben.anhalt at gmail.com> added the comment:

Grrr, the link in my last comment should have been
http://www.nabble.com/System.Net.CookieContainer-adding-inappropriate-%24Port-attribute-to-cookies--td23752882ef1367.html

Yuck.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1564508>
_______________________________________

From report at bugs.python.org  Thu May 28 02:33:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 00:33:31 +0000
Subject: [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: <1243470810.99.0.491297176052.issue6125@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6125>
_______________________________________

From report at bugs.python.org  Thu May 28 02:53:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 May 2009 00:53:06 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243471986.18.0.207851223774.issue6132@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not competent to review Windows-specific stuff, but some style notes:
- your indentation is inconsistent with the original file (you should
use tabs)
- please don't use any C++-style comments

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Thu May 28 03:02:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 01:02:21 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1243472541.0.0.572333049942.issue5673@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Thu May 28 03:02:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 01:02:40 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1243472560.88.0.767003624851.issue5673@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Thu May 28 03:04:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 01:04:21 +0000
Subject: [issue5450] test_tcl testLoadTk fails if DISPLAY defined but connect
	fails, instead of being skipped
In-Reply-To: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>
Message-ID: <1243472661.9.0.134140836998.issue5450@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: gpolo -> r.david.murray
priority:  -> low
stage:  -> needs patch
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5450>
_______________________________________

From report at bugs.python.org  Thu May 28 03:09:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 01:09:05 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1243472945.81.0.742849443031.issue2986@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Documentation, Library (Lib) -Extension Modules
priority:  -> normal
stage:  -> test needed
type:  -> feature request
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu May 28 03:11:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 01:11:40 +0000
Subject: [issue5353] Improve IndexError messages with actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1243473100.19.0.546004252022.issue5353@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________

From report at bugs.python.org  Thu May 28 05:07:42 2009
From: report at bugs.python.org (Alex)
Date: Thu, 28 May 2009 03:07:42 +0000
Subject: [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: <1243480062.48.0.0947277243235.issue6133@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Here's my work so far, it seems to work as described.  Except for the
fact that pyc creation with anything containign something with this
optimization will give a valueerror on bad marshall data, from trying to
marshall the method I assume.

----------
keywords: +patch
Added file: http://bugs.python.org/file14098/python_const_fold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Thu May 28 05:17:31 2009
From: report at bugs.python.org (Alex)
Date: Thu, 28 May 2009 03:17:31 +0000
Subject: [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: <1243480651.72.0.736496011007.issue6133@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Small update so I don't change whitespace all over the plcae.

----------
Added file: http://bugs.python.org/file14099/python_const_fold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Thu May 28 05:23:27 2009
From: report at bugs.python.org (Alex)
Date: Thu, 28 May 2009 03:23:27 +0000
Subject: [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: <1243481007.26.0.497337501783.issue6133@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Switch to using memset instead of a forloop.

----------
Added file: http://bugs.python.org/file14100/python_const_fold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Thu May 28 06:23:18 2009
From: report at bugs.python.org (Alex)
Date: Thu, 28 May 2009 04:23:18 +0000
Subject: [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: <1243484598.34.0.389262888805.issue6133@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

I now *almost* have PyCFunctions marshalling, they seem to marhshall ok
but fail on unmarshalling.  I think the whitespace stuff may have crept
back in, sorry :(

----------
Added file: http://bugs.python.org/file14101/python_const_fold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Thu May 28 07:05:12 2009
From: report at bugs.python.org (James Abbatiello)
Date: Thu, 28 May 2009 05:05:12 +0000
Subject: [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 07:22:43 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 28 May 2009 05:22:43 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243488162.93.0.068598311006.issue6131@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is workaround for reference leak. I'm not sure what exactly leaks
references yet.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file14103/workaround.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

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: [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:10:00 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 28 May 2009 07:10:00 +0000
Subject: [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:24:08 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 May 2009 08:24:08 +0000
Subject: [issue6073] threading.Timer and gtk.main are not compatible
In-Reply-To: <1242852150.25.0.792657695233.issue6073@psf.upfronthosting.co.za>
Message-ID: <1243499048.85.0.828038844176.issue6073@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

When using gtk and threads, it's necessary to call
   gtk.gdk.threads_init()

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6073>
_______________________________________

From report at bugs.python.org  Thu May 28 10:36:21 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 28 May 2009 08:36:21 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243499781.34.0.625585819883.issue6131@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

If I remove distutils.tests.test_config , the leak dissapears. 

I don't understand why yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

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: [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 12:07:43 2009
From: report at bugs.python.org (John Szakmeister)
Date: Thu, 28 May 2009 10:07:43 +0000
Subject: [issue3425] posixmodule.c always using res = utime(path, NULL)
In-Reply-To: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za>
Message-ID: <1243505263.85.0.639273561225.issue3425@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

It seems reasonable to prefer utimes() over utime() in all cases, when 
utimes() is available, since utime() is considered obsolete.  I've 
attached a patch with the required change and ran all the tests.  There 
are some tests failing on trunk with my system.  However this patch 
introduced no additional failures (test_posix passes).  BTW, the patch is 
against trunk.

----------
keywords: +patch
nosy: +jszakmeister
Added file: http://bugs.python.org/file14104/issue-3425-utimes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3425>
_______________________________________

From report at bugs.python.org  Thu May 28 16:28:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 May 2009 14:28:20 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1243520900.03.0.0906343349964.issue1182143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Thu May 28 16:28:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 28 May 2009 14:28:39 +0000
Subject: [issue6048] make distutils use the tarinfo command
In-Reply-To: <1242562795.38.0.0774270839785.issue6048@psf.upfronthosting.co.za>
Message-ID: <1243520919.97.0.397343486501.issue6048@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r72981 and r72984

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6048>
_______________________________________

From report at bugs.python.org  Thu May 28 19:45:18 2009
From: report at bugs.python.org (Niu Zhenyong)
Date: Thu, 28 May 2009 17:45:18 +0000
Subject: [issue5814] SocketServer: TypeError: waitpid() takes no keyword
	arguments
In-Reply-To: <1240402546.97.0.496265243234.issue5814@psf.upfronthosting.co.za>
Message-ID: <1243532718.45.0.682744175935.issue5814@psf.upfronthosting.co.za>


Changes by Niu Zhenyong <nzymail at gmail.com>:


----------
nosy: +nzymail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5814>
_______________________________________

From report at bugs.python.org  Thu May 28 20:32:58 2009
From: report at bugs.python.org (Doug Hellmann)
Date: Thu, 28 May 2009 18:32:58 +0000
Subject: [issue4040] ignored exceptions in generators (regression?)
In-Reply-To: <1223133689.63.0.365168051222.issue4040@psf.upfronthosting.co.za>
Message-ID: <1243535578.86.0.135583222597.issue4040@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4040>
_______________________________________

From report at bugs.python.org  Thu May 28 20:51:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 18:51:53 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243536713.82.0.644394106993.issue5259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

LOGIN and CRAM-MD5 login are fixed in r72990 (3.1) and r72991 (3.0).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Thu May 28 20:52:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 18:52:20 +0000
Subject: [issue5259] smtplib is broken in Python3
In-Reply-To: <1234621158.53.0.153253851523.issue5259@psf.upfronthosting.co.za>
Message-ID: <1243536740.46.0.407683572085.issue5259@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5259>
_______________________________________

From report at bugs.python.org  Thu May 28 22:02:28 2009
From: report at bugs.python.org (Alex)
Date: Thu, 28 May 2009 20:02:28 +0000
Subject: [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: <1243540948.97.0.811090614584.issue6133@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Optimization now works in the shell fine, and
marshal.loads(marshal.dumps(''.join)) works fine in the shell.  However
when I try to run the tests the import of collections.namedtuple causes
the ValueError bad marshal data to appear, and I don't know why.  Could
it have to do with the fact that namedtuple dynamically creates classes
(though I don't see how one of those could ever be the subject of
LOAD_CONST).

----------
Added file: http://bugs.python.org/file14105/python_const_fold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Thu May 28 22:33:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 May 2009 20:33:37 +0000
Subject: [issue6134] 2to3 tests fail on Windows due to line endings
In-Reply-To: <1243487110.56.0.988567820731.issue6134@psf.upfronthosting.co.za>
Message-ID: <1243542817.28.0.0962745733215.issue6134@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch. Applied in r72994.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6134>
_______________________________________

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: [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 report at bugs.python.org  Thu May 28 23:25:32 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 28 May 2009 21:25:32 +0000
Subject: [issue6138] ./configure; make install fails in setup.py step
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1243545932.5.0.950095414853.issue6138@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

works for me under MacOS X, I am trying now under debian

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Thu May 28 23:34:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 21:34:38 +0000
Subject: [issue6138] ./configure; make install fails in setup.py step
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1243546478.52.0.742661537945.issue6138@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin can't reproduce it either.  Must be something weird in my
environment, so I'm lowering the priority.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Thu May 28 23:42:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 May 2009 21:42:25 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1243546945.88.0.908886608943.issue6012@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Patch review:

- It needs docs and tests.
- In addcleanup_convert, Py_FatalError calls abort, so there isn't
really a point of returning -1;
- Also in the function, you need to call destr() in the case that
PyList_Append fails.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Thu May 28 23:44:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 May 2009 21:44:21 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <4A1F05B2.1010203@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 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.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Thu May 28 23:46:51 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 28 May 2009 21:46:51 +0000
Subject: [issue6138] ./configure; make install fails in setup.py step
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1243547211.56.0.944395627087.issue6138@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok.

I confirm it works fine on a standard debian as well

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Thu May 28 23:48:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 21:48:36 +0000
Subject: [issue6138] ./configure; make install fails in setup.py step
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1243547316.09.0.564166701278.issue6138@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can see that 'self.home' is '~' when that error message is generated,
but I can't figure out where self.home gets set.  Any clues you can give me?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Thu May 28 23:51:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 May 2009 21:51:27 +0000
Subject: [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: <1243547487.23.0.0531347439521.issue6133@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. const.attr is not necessarily a constant. Indeed, "".join is *not* a
constant.

Furthermore, using this approach will lead to an endless series of types
to be added to marshalling, which is bad. For example, I believe that
current patch breaks on "".__class__

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri May 29 00:13:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 May 2009 22:13:27 +0000
Subject: [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: <1243548807.72.0.602333067975.issue6133@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would like to see the current patch finished and recorded here for
reference.  But I agree with Martin that changing marshal is a can of
worms.  The peepholer is intended to be conservative and should avoid
anything that has some risk of being complicating our lives.

Another approach may be more successful.  Here's a rough sketch:

in:  LOAD_CONST 5 '{}'   LOAD_ATTR 3 'format' 
out: LOAD_CONST 8 ('{}','format')   LOAD_CONST_ATTR 7.

def LOAD_CONST_ATTR(oparg):
   # cache the lookup of '{}.format' in a fast local
   x = GETLOCAL(oparg)
   if (x == NULL)
       UNPACK 2 --> obj, name
       bm = getattr(obj, name)
       STORE_FAST var
    LOAD_FAST var

----------
assignee:  -> rhettinger
nosy: +rhettinger
type:  -> performance
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri May 29 00:24:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2009 22:24:32 +0000
Subject: [issue6138] './configure;
	make install' fails in setup.py step if .pydistutils.cfg specifies
	'home'
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1243549472.47.0.761116631294.issue6138@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I figured it out.  It turns out that a while back I created a
.pydistutils.cfg file and put home in there.

There is a bug here, of some sort.  Either the .pydistutils.cfg file's
install clause should override the default --prefix somehow, or the
error message should indicate where the setting for 'home' and
'--prefix' came from to enable the user to debug the configuration.  In
the latter case there would also need to be a way to explicitly tell
either make install or configure to ignore .pydistutils.cfg.  In the
former case, an explicit --prefix passed to configure would need to
override .pydistutils.cfg.

Or perhaps there's some other solution I'm not seeing at the moment.

----------
title: ./configure; make install fails in setup.py step -> './configure; make install' fails in setup.py step if .pydistutils.cfg specifies 'home'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Fri May 29 00:35:52 2009
From: report at bugs.python.org (Alex)
Date: Thu, 28 May 2009 22:35:52 +0000
Subject: [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: <1243550152.67.0.155843475153.issue6133@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Fully functional.

----------
Added file: http://bugs.python.org/file14106/python_const_fold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri May 29 00:43:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 May 2009 22:43:28 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1243550608.58.0.583319247518.issue6136@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +vsajip
priority:  -> normal
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6136>
_______________________________________

From report at bugs.python.org  Fri May 29 00:58:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 May 2009 22:58:31 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243551511.57.0.0628676823789.issue6137@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

#3675 is a similar issue, too bad nothing could be done to solve it...

----------
nosy: +alexandre.vassalotti, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Fri May 29 01:18:24 2009
From: report at bugs.python.org (Kevin Watters)
Date: Thu, 28 May 2009 23:18:24 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243552704.87.0.147414344543.issue6132@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Fri May 29 01:26:47 2009
From: report at bugs.python.org (Phillip Sitbon)
Date: Thu, 28 May 2009 23:26:47 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243553207.54.0.591228777585.issue6132@psf.upfronthosting.co.za>


Phillip Sitbon <phillip.sitbon+python-dev at gmail.com> added the comment:

> I'm not competent to review Windows-specific stuff, but 
> some style notes:
> - your indentation is inconsistent with the original file
> (you should use tabs)
> - please don't use any C++-style comments

Thanks- I was only supplying the code for testing purposes, but I will
clean it up anyway... and read the style guide closer of course :)

> 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.

If it were up to me, I'd say move forward with breaking the current
functionality. I guess my statement of "obviously" was that breaking it
outright would cause people to complain. After I got to thinking about
it that way, making GIL locking free from any other API seemed like it
would give more leeway for performance improvement.

If anyone is using the semaphore-like features of threading.Lock, they'd
likely be better off using threading.Semaphore anyway :) There are some
places where the core code would have to change in order to reflect the
differences, but otherwise it would be a significant improvement to the
GIL under high concurrency and not much of a change for a single thread.

On the positive side, a global change means that other core code using
locks will also see a speedup with critical sections as the default
thread lock. So I guess my main point is that somehow, whether separate
from or within the thread lock API, the GIL should be a critical section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Fri May 29 01:56:04 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 28 May 2009 23:56:04 +0000
Subject: [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 02:04:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 00:04:14 +0000
Subject: [issue6139] Typo in email.base64mime
In-Reply-To: <1243554963.67.0.192911044449.issue6139@psf.upfronthosting.co.za>
Message-ID: <1243555454.6.0.565394184588.issue6139@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Library (Lib)
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6139>
_______________________________________

From report at bugs.python.org  Fri May 29 02:05:17 2009
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 29 May 2009 00:05:17 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1243555517.36.0.0553246860537.issue5150@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Here's an extension that adds rstrip() to the Format menu.

----------
nosy: +serwy
Added file: http://bugs.python.org/file14108/RstripExtension.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Fri May 29 03:01:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 01:01:34 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1243558894.07.0.118272094122.issue5596@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

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: [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 03:23:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 May 2009 01:23:17 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1243560197.26.0.267006530684.issue5150@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r72999.  Will backport to 2.7.

----------
assignee: kbk -> rhettinger
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Fri May 29 03:23:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 01:23:45 +0000
Subject: [issue6140] configure error: shadow.h: present but cannot be compiled
In-Reply-To: <1243560059.83.0.307213103103.issue6140@psf.upfronthosting.co.za>
Message-ID: <1243560225.18.0.137352223917.issue6140@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

2.5 is in security-fix-only mode.  Is this problem reproducible with 2.6?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6140>
_______________________________________

From report at bugs.python.org  Fri May 29 03:25:29 2009
From: report at bugs.python.org (Sashi)
Date: Fri, 29 May 2009 01:25:29 +0000
Subject: [issue6140] configure error: shadow.h: present but cannot be compiled
In-Reply-To: <1243560059.83.0.307213103103.issue6140@psf.upfronthosting.co.za>
Message-ID: <1243560329.65.0.0639299535284.issue6140@psf.upfronthosting.co.za>


Sashi <sashi at voltage.com> added the comment:

Have not tried it on 2.6 - Will update when I get a chance to build 2.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6140>
_______________________________________

From report at bugs.python.org  Fri May 29 03:52:34 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 May 2009 01:52:34 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1243561954.97.0.567604959128.issue5150@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Backported in r73001

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Fri May 29 03:58:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 May 2009 01:58:40 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1243562320.77.0.470799084354.issue6095@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If this is to go into Py3.1, it needs to happen quickly.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Fri May 29 04:46:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 May 2009 02:46:23 +0000
Subject: [issue818059] os.listdir on empty strings. Inconsistent behaviour.
Message-ID: <1243565183.47.0.16075762824.issue818059@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Superseded by #5913.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> On Windows os.listdir('') -> cwd and os.listdir(u'') -> C:\

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue818059>
_______________________________________

From report at bugs.python.org  Fri May 29 07:00:56 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 May 2009 05:00:56 +0000
Subject: [issue5982] classmethod, staticmethod: expose wrapped function
In-Reply-To: <1241903103.58.0.38956766589.issue5982@psf.upfronthosting.co.za>
Message-ID: <1243573256.34.0.620759730085.issue5982@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r73005 and r73006

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5982>
_______________________________________

From report at bugs.python.org  Fri May 29 08:45:25 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 29 May 2009 06:45:25 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243579525.73.0.455382376522.issue6131@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I can reproduce refleaks with only test_distutils now.

E:\python-dev\py3k\Lib\test>py3k regrtest.py -R3:2: test_distutils
test_distutils
beginning 5 repetitions
12345
.....
test_distutils leaked [280, 280] references, sum=560
1 test failed:
    test_distutils

I think this refleaks can be solved by using super() for setUp() and
tearDown() everywhere.

----------
Added file: http://bugs.python.org/file14109/fix_distutils_refleak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 09:06:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 May 2009 07:06:39 +0000
Subject: [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: <1243580799.17.0.41577556014.issue6097@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6097>
_______________________________________

From report at bugs.python.org  Fri May 29 09:37:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 May 2009 07:37:14 +0000
Subject: [issue5274] sys.exc_info()[1] - different handling from str() and
	unicode() - py 2.6
In-Reply-To: <1234734636.9.0.12200425592.issue5274@psf.upfronthosting.co.za>
Message-ID: <1243582634.65.0.892669349799.issue5274@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Duplicate of #6108.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> unicode(exception) behaves differently on Py2.6 when len(exception.args) > 1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5274>
_______________________________________

From report at bugs.python.org  Fri May 29 10:06:20 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 May 2009 08:06:20 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243584380.5.0.162456393215.issue6131@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 10:11:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 May 2009 08:11:39 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243584699.79.0.917734435084.issue6131@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks, it fixed it. Applied in the trunk. 

Can you guys merge r73008 into Py3k please ? 

I have a problem today, I can't build py3k on Mac OS X anymore, I am
trying to figure out why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 11:33:15 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 29 May 2009 09:33:15 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243589595.76.0.530333718992.issue6131@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Done in r73010. I think it would be better to patch release26maint.patch
for release26-maint (and same patch for release30-maint) to complete
super() issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 11:34:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 29 May 2009 09:34:57 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243589697.09.0.283395422613.issue6131@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file14110/release26maint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 12:06:49 2009
From: report at bugs.python.org (John Szakmeister)
Date: Fri, 29 May 2009 10:06:49 +0000
Subject: [issue4829] confusing error for file("foo", "w++")
In-Reply-To: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>
Message-ID: <1243591609.88.0.974295113787.issue4829@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

On trunk, it seems that it's perfectly happy if you specify more than 
one '+':

Python 2.7a0 (trunk, May 29 2009, 05:57:26) 
[GCC 4.0.1 (Apple Inc. build 5470) (Aspen 5470.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open('foo.txt', 'w++')
<open file 'foo.txt', mode 'w++' at 0x39b2a0>

Is this still really an issue then?  The current trunk also allows 
multiple mode letters too, so it seems like a decision has been made.

----------
nosy: +jszakmeister

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4829>
_______________________________________

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: [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 12:14:50 2009
From: report at bugs.python.org (John Szakmeister)
Date: Fri, 29 May 2009 10:14:50 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1243592090.26.0.00389622289051.issue3329@psf.upfronthosting.co.za>


Changes by John Szakmeister <john at szakmeister.net>:


----------
nosy: +jszakmeister

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Fri May 29 12:26:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 May 2009 10:26:24 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243592784.08.0.442872138778.issue6131@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done thx for the help.

Do you happen to know the exact reason why using super rather than an
explicit call avoids the leaking ?

----------
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 12:31:37 2009
From: report at bugs.python.org (John Szakmeister)
Date: Fri, 29 May 2009 10:31:37 +0000
Subject: [issue4618] print_function and unicode_literals don't work together
In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za>
Message-ID: <1243593097.02.0.221579446658.issue4618@psf.upfronthosting.co.za>


Changes by John Szakmeister <john at szakmeister.net>:


----------
nosy: +jszakmeister

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4618>
_______________________________________

From report at bugs.python.org  Fri May 29 12:39:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 29 May 2009 10:39:54 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243593594.37.0.542468040903.issue6131@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, I don't know... But probably mixing super() and non super() caused
too many call of setUp() or tearDown(). I saw such case before.

To track down this, probably this info helps.
1. Revert to previous revision of distutils
2. Remove distutils tests except for test_archive_util.py and
test_bdist_dumb.py
3. Run regrtest.py -R2:3: test_distutils

test_distutils
beginning 5 repetitions
12345
.....
test_distutils leaked [280, 280] references, sum=560
1 test failed:
    test_distutils

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 13:28:59 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 29 May 2009 11:28:59 +0000
Subject: [issue6131] test_modulefinder leaks when run after test_distutils
In-Reply-To: <1243461386.21.0.926322558981.issue6131@psf.upfronthosting.co.za>
Message-ID: <1243596539.07.0.088342592518.issue6131@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I tracked down more deeper.

LoggingSilencer.setUp() was called twice, so restoration of log.Log._log
was not done correctly. log.Log._log becomes method of TestCase class
after test done in most cases. Probably this keeps reference to TestCase
and its instance variables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6131>
_______________________________________

From report at bugs.python.org  Fri May 29 16:07:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 May 2009 14:07:53 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1243606073.52.0.315275831496.issue672115@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Lars, I think that your question has a simple explanation, and is not
related to the original issue:
- On 4th line, the variable named "A" is bound to a new type object.
This type has no attribute by itself.
- The first dir(A) displays the attributes of the bases class, which are
the previous A and B: you see ['one', 'two']
- The second dir(A) displays the attributes of the bases class, which
are B and C: you see ['two', 'three']

The instruction "A = type(...)" causes A to refer to another object; it
does not change the object previously contained in A.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue672115>
_______________________________________

From report at bugs.python.org  Fri May 29 16:50:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 14:50:27 +0000
Subject: [issue6012] enhance getargs O& to accept cleanup function
In-Reply-To: <1242215180.04.0.473547088892.issue6012@psf.upfronthosting.co.za>
Message-ID: <1243608627.29.0.0181030284523.issue6012@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed this patch with the proposed modifications as r73014.

I don't believe that the additional destr call is necessary, as
releasing the capsule will invoke destr already.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6012>
_______________________________________

From report at bugs.python.org  Fri May 29 17:17:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 15:17:40 +0000
Subject: [issue6141] missing first argument on subprocess.Popen w/ executable
In-Reply-To: <1243591610.71.0.101419650032.issue6141@psf.upfronthosting.co.za>
Message-ID: <1243610260.76.0.450873636669.issue6141@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The way it works is the way most programmers expect it to work, even
though most get bitten by it more than once.  So the behavior isn't
going to change.  I've attached a doc fix, but I'm not sure whether or
not the 'diplay name' piece applies only to unix, although I've
documented it that way.  The windows documentation I found for
CreateProcess does not mention it, though it does note that "most C
programmers" treat argv[0] as the process name, consistent with the way
subprocess handles the argument string.

The Windows documentation I consulted is here:

http://msdn.microsoft.com/en-us/library/ms682425.aspx

----------
keywords: +patch
nosy: +r.david.murray
priority:  -> normal
versions:  -Python 2.5
Added file: http://bugs.python.org/file14111/issue6141-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6141>
_______________________________________

From report at bugs.python.org  Fri May 29 17:23:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 15:23:39 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1243610619.0.0.42752090983.issue4859@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patches. Committed as r73015.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

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: [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 18:05:22 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 16:05:22 +0000
Subject: [issue4873] Refcount error and file descriptor leaks in pwd,
	grp modules
In-Reply-To: <1231367446.48.0.542903635557.issue4873@psf.upfronthosting.co.za>
Message-ID: <1243613122.22.0.18339616491.issue4873@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r73016, r73017, r73018, r73019.

----------
nosy: +loewis
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4873>
_______________________________________

From report at bugs.python.org  Fri May 29 18:22:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 16:22:47 +0000
Subject: [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: <1243614167.41.0.334611251078.issue6097@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r73020.

----------
nosy: +loewis
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6097>
_______________________________________

From report at bugs.python.org  Fri May 29 18:27:47 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 29 May 2009 16:27:47 +0000
Subject: [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: <1243614467.07.0.448505250326.issue6133@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri May 29 18:37:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 16:37:21 +0000
Subject: [issue5903] strftime fails in non UTF-8 locale
In-Reply-To: <1241270355.41.0.0522158761991.issue5903@psf.upfronthosting.co.za>
Message-ID: <1243615041.51.0.858527991843.issue5903@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of issue 3061.

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> time.strftime() always decodes result with UTF-8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5903>
_______________________________________

From report at bugs.python.org  Fri May 29 18:37:52 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 16:37:52 +0000
Subject: [issue5562] Locale-based date formatting crashes on non-ASCII data
In-Reply-To: <1238010378.87.0.1611631381.issue5562@psf.upfronthosting.co.za>
Message-ID: <1243615072.96.0.835493310406.issue5562@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of issue 3061.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> time.strftime() always decodes result with UTF-8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5562>
_______________________________________

From report at bugs.python.org  Fri May 29 18:48:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 16:48:02 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1243615682.96.0.0477991388019.issue3585@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Antoine: Don't use autoconf 2.63 to generate pyconfig.h.in and
configure. Use 2.61 instead (until it is agreed to switch to a newer
version).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Fri May 29 19:29:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 17:29:07 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1243618147.01.0.682652098336.issue3061@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch that resolves this issue for systems supporting
wcsftime, which should be the majority of systems on which the problem
can occur.

----------
keywords: +patch
priority: high -> release blocker
Added file: http://bugs.python.org/file14113/wcsftime.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Fri May 29 19:57:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 May 2009 17:57:16 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1243615682.96.0.0477991388019.issue3585@psf.upfronthosting.co.za>
Message-ID: <1243619966.5435.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine: Don't use autoconf 2.63 to generate pyconfig.h.in and
> configure. Use 2.61 instead (until it is agreed to switch to a newer
> version).

Oops, sorry. Are there any known issues with 2.63?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Fri May 29 20:07:22 2009
From: report at bugs.python.org (jamesie)
Date: Fri, 29 May 2009 18:07:22 +0000
Subject: [issue6092] Changed Shortcuts don't show up in menu
In-Reply-To: <1243060734.82.0.446246510061.issue6092@psf.upfronthosting.co.za>
Message-ID: <1243620442.55.0.756595239268.issue6092@psf.upfronthosting.co.za>


jamesie <post06 at jamesie.de> added the comment:

At least for Run in the main menu the changed shortcut shows up after a
restart of IDLE. Nevertheless in the Options dialog the string "F5"
seems to be hard coded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6092>
_______________________________________

From report at bugs.python.org  Fri May 29 20:45:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 May 2009 18:45:00 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1243622700.25.0.7801454.issue3061@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch looks good. (Can this be tested?)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Fri May 29 20:58:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 May 2009 18:58:12 +0000
Subject: [issue6141] missing first argument on subprocess.Popen w/ executable
In-Reply-To: <1243591610.71.0.101419650032.issue6141@psf.upfronthosting.co.za>
Message-ID: <1243623492.38.0.0110393922628.issue6141@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good, just replace `ps` by :program:`ps` please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6141>
_______________________________________

From report at bugs.python.org  Fri May 29 21:26:53 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 19:26:53 +0000
Subject: [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: <1243625213.07.0.284665323768.issue6102@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Am closing based on 'My problem seems resolved'.
I don't know whether it will be fixed in 3.0.2 or not,
but that is pretty much a moot point.

----------
nosy: +tjreedy
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6102>
_______________________________________

From report at bugs.python.org  Fri May 29 21:29:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 19:29:59 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1243625399.21.0.626026665685.issue3061@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's difficult to test. The only test I can think of is one that gets
skipped if the fr_FR (say) locale is not configured. The test would then
try to find out what the name of February is, which should return a
string (see issue5562).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Fri May 29 21:31:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 19:31:09 +0000
Subject: [issue6141] missing first argument on subprocess.Popen w/ executable
In-Reply-To: <1243591610.71.0.101419650032.issue6141@psf.upfronthosting.co.za>
Message-ID: <1243625469.06.0.307396980214.issue6141@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r73026, thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6141>
_______________________________________

From report at bugs.python.org  Fri May 29 21:41:39 2009
From: report at bugs.python.org (Phillip Sitbon)
Date: Fri, 29 May 2009 19:41:39 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243626099.33.0.538138860136.issue6132@psf.upfronthosting.co.za>


Changes by Phillip Sitbon <phillip.sitbon+python-dev at gmail.com>:


Removed 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  Fri May 29 21:43:15 2009
From: report at bugs.python.org (Phillip Sitbon)
Date: Fri, 29 May 2009 19:43:15 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243626195.1.0.213563523324.issue6132@psf.upfronthosting.co.za>


Phillip Sitbon <phillip.sitbon+python-dev at gmail.com> added the comment:

Tabified new code and removed one C++-style comment.

----------
Added file: http://bugs.python.org/file14114/thread_nt.h.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Fri May 29 21:47:18 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 19:47:18 +0000
Subject: [issue6119] Confusing DeprecationWarning
In-Reply-To: <1243373041.06.0.391551220918.issue6119@psf.upfronthosting.co.za>
Message-ID: <1243626438.26.0.847679688755.issue6119@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe that is a bug.  The warning should be about 'order
comparisons', which did disappear, and not 'inequality comparisons', and
should not trigger on == or !=.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6119>
_______________________________________

From report at bugs.python.org  Fri May 29 22:06:44 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 20:06:44 +0000
Subject: [issue6127] Unexpected universal newline behavior (newline
	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1243627604.52.0.511157852101.issue6127@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

FWIW, WindowsXP, Py3.1b1, May 7

>>> io.StringIO('foo\r\nbar\r\n', newline=None).read()
'foo\nbar\n'

I believe there were changes to io after April 14 for May 7 release, so
this may be fixed in 2.6.3 branch already.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6127>
_______________________________________

From report at bugs.python.org  Fri May 29 22:08:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 20:08:07 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1243627687.35.0.262550340904.issue5922@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This was applied by Georg in r72925.

----------
nosy: +r.david.murray
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5922>
_______________________________________

From report at bugs.python.org  Fri May 29 22:20:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 20:20:05 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1243628405.86.0.961401440776.issue3061@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Fri May 29 22:25:01 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 20:25:01 +0000
Subject: [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: <1243628701.02.0.238860963294.issue6133@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin, I agree that we would have to think carefully about all
attributes of all constants loaded by LOAD_CONST, and about
special-casing marshal, but given that "'str' object attribute 'join' is
read-only", how is ''.join not a constant?  Do you have another example
in mind?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri May 29 22:29:01 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 May 2009 20:29:01 +0000
Subject: [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: <1243628941.44.0.46960289577.issue6133@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm working a better patch now.  Will give to collin to review when it's
ready.  Here's a draft of the new opcode:

		TARGET(LOAD_CONST_ATTR)
			u = GETLOCAL(oparg);	/* Cached attribute or NULL */
			t = TOP();				/* t = (obj, name) where obj is constant */
			if (u != NULL) {		/* If cache is non-null, use it */
				Py_INCREF(u);
				SET_TOP(u);
				Py_DECREF(t);
				FAST_DISPATCH();
			}
			/* Cache is empty, do regular attribute lookup */
			assert(PyTuple_CheckExact(t) && Py_SIZE(t) == 2);
			v = PyTuple_GET_ITEM(t, 0);
			w = PyTuple_GET_ITEM(t, 1);
			x = PyObject_GetAttr(v, w);
			Py_DECREF(t);
			if (x != NULL) {		/* Successful lookup; cache it and return */
				SETLOCAL(oparg, x);
				Py_INCREF(x);
				SET_TOP(x);
				break;
			}
			STACKADJ(-1);			/* Attribute not found; goto err handler */
			break;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri May 29 22:31:57 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 May 2009 20:31:57 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1243629117.52.0.585224479864.issue3061@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Can you use test_support.run_with_locale?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Fri May 29 22:39:39 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 20:39:39 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1243629579.68.0.741075224571.issue2292@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I was hoping this would make 3.1.  Too late, I guess.  What about 3.2?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Fri May 29 22:41:08 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 20:41:08 +0000
Subject: [issue6100] Expanding arrays inside other arrays
In-Reply-To: <1243204212.24.0.875545210222.issue6100@psf.upfronthosting.co.za>
Message-ID: <1243629668.59.0.563504388171.issue6100@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree.  This and more is part of #2292

----------
nosy: +tjreedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Missing *-unpacking generalizations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6100>
_______________________________________

From report at bugs.python.org  Fri May 29 22:42:59 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 May 2009 20:42:59 +0000
Subject: [issue6139] Typo in email.base64mime
In-Reply-To: <1243554963.67.0.192911044449.issue6139@psf.upfronthosting.co.za>
Message-ID: <1243629779.92.0.535282219492.issue6139@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r73028.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6139>
_______________________________________

From report at bugs.python.org  Fri May 29 22:44:20 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 29 May 2009 20:44:20 +0000
Subject: [issue6001] Test discovery for unittest
In-Reply-To: <1242078042.33.0.474708922621.issue6001@psf.upfronthosting.co.za>
Message-ID: <1243629860.83.0.70996064334.issue6001@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 73027.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6001>
_______________________________________

From report at bugs.python.org  Fri May 29 22:52:33 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 May 2009 20:52:33 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1243630353.47.0.72068619204.issue2292@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> I was hoping this would make 3.1.  Too late, I guess.  What about 3.2?

Here's what I said before:

"""
I think we should either get this into the 3.0a5 release planned for May
7, or wait for 3.1.  I'd prefer to see some kind of PEP discussion on
the python-3000 list, rather than just a BDFL approval in a tracker
issue.  I think it's a useful feature (especially now we already have
PEP 3132) but we're getting close to the release, so I'd like to see
some more eyeballs on this code...  I expect the PEP discussion will be
short and sweet -- either most folks like it, or we should not push
through at this point in time.
"""

I still think this is the way to do it.  I'm +0 myself.  We might decide
not to do it just because py3k needs stability more than it needs more
features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Fri May 29 22:54:47 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 May 2009 20:54:47 +0000
Subject: [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: <1243630487.6.0.269429718004.issue6133@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a rough patch for caching constant attribute lookups.   Has an
open TODO for adding the new name to co->co_varnames.

----------
Added file: http://bugs.python.org/file14115/constattr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

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: [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: [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  Fri May 29 23:46:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 21:46:08 +0000
Subject: [issue3821] trace module bug when using --missing
In-Reply-To: <1220976433.09.0.355914664139.issue3821@psf.upfronthosting.co.za>
Message-ID: <1243633568.48.0.565539104325.issue3821@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Brett Cannon apparently fixed this in r69111 for 3.1.  I merged it to
the 30-maint branch in r73030.

It would be nice to add the tests, but they don't currently pass
(test_coverage_ignore fails).  I don't know if that's a test bug or a
code bug, not being familiar with the trace module.

----------
nosy: +r.david.murray
priority: critical -> low
resolution:  -> fixed
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3821>
_______________________________________

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: [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 00:24:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 22:24:45 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1243635885.86.0.724868316978.issue4236@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Interpreter Core
stage:  -> needs patch
type:  -> crash
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Sat May 30 00:31:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 22:31:33 +0000
Subject: [issue4486] Exception traceback is incorrect for strange exception
	handling
In-Reply-To: <1228214038.9.0.934760513423.issue4486@psf.upfronthosting.co.za>
Message-ID: <1243636293.97.0.969748759149.issue4486@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: barry -> 
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4486>
_______________________________________

From report at bugs.python.org  Sat May 30 00:34:56 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 22:34:56 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1243619966.5435.0.camel@localhost>
Message-ID: <4A20630C.8040609@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Oops, sorry. Are there any known issues with 2.63?

Yes: it puts a carriage-return character into configure
which completely confuses subversion.

I'm puzzled how you were able to commit the generated
files; subversion should have reported an error

svn: File 'configure' has inconsistent newlines
svn: Inconsistent line ending style

See

http://mail.python.org/pipermail/python-dev/2008-November/083781.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sat May 30 00:38:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 May 2009 22:38:59 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <4A20630C.8040609@v.loewis.de>
Message-ID: <1243636869.5435.3.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes: it puts a carriage-return character into configure
> which completely confuses subversion.
> 
> I'm puzzled how you were able to commit the generated
> files; subversion should have reported an error
> 
> svn: File 'configure' has inconsistent newlines
> svn: Inconsistent line ending style

I did get that message (and got puzzled by it).
I worked around it by reading the file in universal newlines mode and
saving it again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sat May 30 00:43:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 22:43:40 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1243637020.57.0.776076311566.issue1563@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Reducing priority since the critical issues seem to have been resolved
already.  Also retargeting for 3.2 since 3.1 is about to go rc.

----------
nosy: +r.david.murray
priority: critical -> normal
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Sat May 30 00:45:38 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 22:45:38 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to
	just	be a LOAD_COST
In-Reply-To: <1243628701.02.0.238860963294.issue6133@psf.upfronthosting.co.za>
Message-ID: <4A20658F.30305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Terry J. Reedy wrote:
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Martin, I agree that we would have to think carefully about all
> attributes of all constants loaded by LOAD_CONST, and about
> special-casing marshal, but given that "'str' object attribute 'join' is
> read-only", how is ''.join not a constant?  

py> s = ""
py> s.join is s.join
False

Every time you read it, you get a new object. Not what I would call a
constant. If you don't see how this matters, try

def foo():
  return "".join

print foo() is foo()

with and without your patch.

----------
title: LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST -> 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  Sat May 30 00:52:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 22:52:35 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1243629117.52.0.585224479864.issue3061@psf.upfronthosting.co.za>
Message-ID: <4A206730.3030401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Benjamin Peterson wrote:
> Benjamin Peterson <benjamin at python.org> added the comment:
> 
> Can you use test_support.run_with_locale?

I don't think so. IIUC, run_with_locale will fallback to not
setting the locale if none of the listed locales actually works
on the system. This would be undesirable for this issue - it
would be a proper test only if you have a locale for which
strftime currently fails (i.e. returns non-ASCII characters,
and doesn't use UTF-8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Sat May 30 00:55:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 May 2009 22:55:25 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <4A206730.3030401@v.loewis.de>
Message-ID: <1afaf6160905291555x3da9090dh80b151f1234bf2bb@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/5/29 Martin v. L?wis <report at bugs.python.org>:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Benjamin Peterson wrote:
>> Benjamin Peterson <benjamin at python.org> added the comment:
>>
>> Can you use test_support.run_with_locale?
>
> I don't think so. IIUC, run_with_locale will fallback to not
> setting the locale if none of the listed locales actually works
> on the system. This would be undesirable for this issue - it
> would be a proper test only if you have a locale for which
> strftime currently fails (i.e. returns non-ASCII characters,
> and doesn't use UTF-8).

Well, I think you should just apply the patch then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Sat May 30 01:01:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 May 2009 23:01:15 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1243638075.05.0.882008176605.issue2775@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Sat May 30 01:04:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 23:04:08 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1243636869.5435.3.camel@localhost>
Message-ID: <4A2069E3.5040802@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I did get that message (and got puzzled by it).
> I worked around it by reading the file in universal newlines mode and
> saving it again.

I believe this has broken part of the configure script. There is an
ac_cr variable that is supposed to hold a sole carriage-return
character; it now holds a newline character instead. This will break
the test whether the system autoconf deals with carriage-return
characters correctly, which probably means that it may decide to use
awk to do file substitution when it should have been using /bin/sh,
or vice versa (I haven't fully understood the purpose of this test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sat May 30 01:16:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 May 2009 23:16:02 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <4A2069E3.5040802@v.loewis.de>
Message-ID: <1243639092.5435.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ouch, unfortunately it seems my distribution doesn't package autoconf
2.61. Is there any risk in installing it from scratch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

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: [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 01:22:20 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 May 2009 23:22:20 +0000
Subject: [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: <1243639340.85.0.864314160074.issue6133@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You are right, of course: bound methods are currently created fresh on
each access, even though each is equal except for identity.  I was
thinking in terms of 
>>> str.join is str.join
True

This appears to be a classic time-space tradeoff: caching bound methods,
which is what I understand Raymond's patch does (when the attribute is a
method), saves time (with enough reuses) but takes space that could
gradually grow.

The reply to the OP could be that people who care about time should use
the standard idiom of explicitly  savingthe bound method:
>>> bjoin = ''.join
...
On the other hand, such bindings look a bit messy and tend to be local.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Sat May 30 01:42:44 2009
From: report at bugs.python.org (Humberto Diogenes)
Date: Fri, 29 May 2009 23:42:44 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243640564.51.0.473635209838.issue2919@psf.upfronthosting.co.za>


Humberto Diogenes <humberto at digi.com.br> added the comment:

How is this going?

----------
nosy: +hdiogenes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Sat May 30 01:50:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 May 2009 23:50:05 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1243639092.5435.4.camel@localhost>
Message-ID: <4A2074AA.5010400@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ouch, unfortunately it seems my distribution doesn't package autoconf
> 2.61. Is there any risk in installing it from scratch?

I usually install it into a private location, such as ~/ac261. This is
absolutely safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Sat May 30 02:01:21 2009
From: report at bugs.python.org (Gordon Fogus)
Date: Sat, 30 May 2009 00:01:21 +0000
Subject: [issue2742] example code does not work
In-Reply-To: <1209754679.55.0.840137197769.issue2742@psf.upfronthosting.co.za>
Message-ID: <1243641681.27.0.0324081887029.issue2742@psf.upfronthosting.co.za>


Gordon Fogus <gordon.fogus at gmail.com> added the comment:

I am having this issue again with python code running under python 2.6.2
compiled from source on May 28, 2009 in CentOS 5.3.  The patch in the
socketmodule.diff file does not seem to be applied to the socketmodule.c
file in the current 2.6.2 in
http://www.python.org/ftp/python/2.6.2/Python-2.6.2.tgz .

I need to be able to bind a port all interfaces to listen to responses
from a server.  This currently only works under windows due to this
issue.  Linux does not like the blank "" IP address; it requires a NULL.

Please advise on a workaround or new patch for this issue.

----------
components: +IO -Documentation
nosy: +fogus
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2742>
_______________________________________

From report at bugs.python.org  Sat May 30 02:04:42 2009
From: report at bugs.python.org (Collin Winter)
Date: Sat, 30 May 2009 00:04:42 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just
	be a LOAD_COST
In-Reply-To: <4A20658F.30305@v.loewis.de>
Message-ID: <43aa6ff70905291704p2a1c655cia472d7149f8913f7@mail.gmail.com>


Collin Winter <collinw at gmail.com> added the comment:

On Fri, May 29, 2009 at 3:45 PM, Martin v. L?wis <report at bugs.python.org> wrote:
> py> s = ""
> py> s.join is s.join
> False
>
> Every time you read it, you get a new object. Not what I would call a
> constant. If you don't see how this matters, try
>
> def foo():
> ?return "".join
>
> print foo() is foo()
>
> with and without your patch.

The fact that it returns a new object every time seems like an
implementation detail, and one that users find confusing (I know I
once filed a bug about it).

One problem I recognize is that the proposed patch would presumably
create an asymmetry between "x".join is "x".join and "x = 'x'; x.join
is x.join" where the former would evaluate to True and the latter to
False. That seems surmountable, though.

----------
title: LOAD_CONST followed by LOAD_ATTR can be optimized to just	be a LOAD_COST -> 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  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: [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 02:09:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 00:09:40 +0000
Subject: [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: <1243642180.82.0.128314045703.issue6133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does this optimization actually help in real-world cases?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Sat May 30 02:39:50 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 May 2009 00:39:50 +0000
Subject: [issue6147] multithreading.Pool.map() crashes Windows computer
In-Reply-To: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>
Message-ID: <1243643990.41.0.362814755697.issue6147@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller
status: open -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6147>
_______________________________________

From report at bugs.python.org  Sat May 30 03:30:26 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Sat, 30 May 2009 01:30:26 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1243647026.35.0.461482332405.issue1563@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

You can probably close this unless someone says otherwise.  asyncore/asynchat work in Python 3.0+, as long as only bytes are passed.  
As of right now, this is a request for documentation stating "you can only 
send/receive bytes"...which may be implicit with the fact that we are 
reading/writing to sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Sat May 30 03:44:51 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 30 May 2009 01:44:51 +0000
Subject: [issue6147] multithreading.Pool.map() crashes Windows computer
In-Reply-To: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>
Message-ID: <1243647891.4.0.653876302833.issue6147@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Can you wrap the execution of the main code in a if __name__ == 
"__main__": block, as shown in the documentation? Failure to do so can 
cause a fork bomb on windows

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6147>
_______________________________________

From report at bugs.python.org  Sat May 30 05:09:48 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 May 2009 03:09:48 +0000
Subject: [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: <1243652988.43.0.507707949175.issue6133@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Returning the same object vs new object for bound methods is a
non-guaranteed implementation detail (as long the other semantics remain
true).   I think Martin's real concern is that trying to intern bound
methods would be a can of worms (one that I wouldn't want to open).

FWIW, str.join ignored by this patch.  The "str" builtin is an
overridable builtin (LOAD_GLOBAL "str" LOAD_ATTR "join").  In contrast,
",".join or "{}".format does not have dynamically changeable behavior
(LOAD_CONST "{}" LOAD_ATTR "format").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Sat May 30 05:14:49 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 May 2009 03:14:49 +0000
Subject: [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: <1243653289.28.0.139618064922.issue6133@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

[AP]
> Does this optimization actually help in real-world cases?

Yes and no.  Yes, there are real world cases like ','.join and
'{}'.format that are dramatically sped-up.  No, there are probably no
real-world programs that are sped-up significantly in their entirety --
no one optimization will ever do that (Amdahl's law).  Pretty much
anytime the substitution gets made there is a savings on second and
subsequent calls (just like any form of caching).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Sat May 30 07:18:15 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 May 2009 05:18:15 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to
	just	be a LOAD_COST
In-Reply-To: <1243652988.43.0.507707949175.issue6133@psf.upfronthosting.co.za>
Message-ID: <4A20C13E.4080205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Returning the same object vs new object for bound methods is a
> non-guaranteed implementation detail (as long the other semantics remain
> true).   I think Martin's real concern is that trying to intern bound
> methods would be a can of worms (one that I wouldn't want to open).

I'm also concerned about the change in behavior. Whether or not it is
guaranteed - some code in the world *will* notice. IMO, optimizations
should only be implemented if there is no change in observable behavior,
or if the improvement is so large that breaking compatibility is
justified.

----------
title: LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST -> 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  Sat May 30 08:16:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 May 2009 06:16:16 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1243664176.94.0.402765187641.issue3061@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r73043, r73044

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Sat May 30 08:37:22 2009
From: report at bugs.python.org (Ian Miers)
Date: Sat, 30 May 2009 06:37:22 +0000
Subject: [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 08:55:23 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 May 2009 06:55:23 +0000
Subject: [issue6148] Help well execute code it is called on
In-Reply-To: <1243665441.27.0.193785694569.issue6148@psf.upfronthosting.co.za>
Message-ID: <1243666523.39.0.530214151659.issue6148@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Default args are evaluated when the module is imported, if the arg is a
function call, the function is called.
You can see how the file is created just after the import, you don't
even need to call help().

This behavior is documented here:
http://docs.python.org/tutorial/controlflow.html#default-argument-values

The doc doesn't mention explicitly function calls, that could be added.

----------
components:  -Interpreter Core
nosy: +ezio.melotti
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6148>
_______________________________________

From report at bugs.python.org  Sat May 30 09:17:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 May 2009 07:17:12 +0000
Subject: [issue6148] Help well execute code it is called on
In-Reply-To: <1243665441.27.0.193785694569.issue6148@psf.upfronthosting.co.za>
Message-ID: <1243667832.84.0.724078282172.issue6148@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ezio is correct.  The file is already created while importing bug, not
due to the call to help().

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6148>
_______________________________________

From report at bugs.python.org  Sat May 30 09:26:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 May 2009 07:26:13 +0000
Subject: [issue6146] markup error in Doc/library/rlcompleter.rst
In-Reply-To: <1243639257.69.0.988766208068.issue6146@psf.upfronthosting.co.za>
Message-ID: <1243668373.55.0.00310039357233.issue6146@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r73045.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6146>
_______________________________________

From report at bugs.python.org  Sat May 30 10:05:11 2009
From: report at bugs.python.org (Lars)
Date: Sat, 30 May 2009 08:05:11 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1243670711.3.0.761991377554.issue672115@psf.upfronthosting.co.za>


Lars <gemerden at gmail.com> added the comment:

ok, i see what you mean, for me at this time the most important question
is whta does 

class object(object)
    pass

do, why can i change baseclasses after i redeclare object this way, and
will it get me into trouble when i use this to let users dynamically
define classes and inheritence relationships?

cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue672115>
_______________________________________

From report at bugs.python.org  Sat May 30 14:42:38 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 30 May 2009 12:42:38 +0000
Subject: [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: <1243687358.54.0.254777739524.issue6022@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Hi All,
The test always fails even builddir == srddir , with and without
directory links in src-/build-path. 

$ LD_LIBRARY_PATH=`pwd` ./python
Python 2.7a0 (trunk:73046M, May 30 2009, 14:09:06)
[GCC 4.2.4] on linux2
....

$ cat /tmp/pynexttest
test_distutils

The command to run test is:
$ LC_ALL=C ./python -E -tt ./Lib/test/regrtest.py -l -v -s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From report at bugs.python.org  Sat May 30 14:45:10 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 30 May 2009 12:45:10 +0000
Subject: [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: <1243687510.38.0.55807009673.issue6022@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

P.S.: the test command start with LD_LIBRARY_PATH=`pwd`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From report at bugs.python.org  Sat May 30 18:09:42 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 May 2009 16:09:42 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1243699782.86.0.385187684407.issue5922@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d like to know whether my suggestion was rejected or merely overlooked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5922>
_______________________________________

From report at bugs.python.org  Sat May 30 19:53:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 May 2009 17:53:51 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1243706031.7.0.149082668618.issue5922@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Probably overlooked.  Perhaps Georg will comment definitively later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5922>
_______________________________________

From report at bugs.python.org  Sat May 30 19:55:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 May 2009 17:55:20 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1243706120.69.0.70344936246.issue5922@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I overlooked it, yes. But it also seems to me that it's no major problem :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5922>
_______________________________________

From report at bugs.python.org  Sat May 30 20:04:49 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 May 2009 18:04:49 +0000
Subject: [issue5922] Multi-with patch
In-Reply-To: <1241447390.49.0.864181640447.issue5922@psf.upfronthosting.co.za>
Message-ID: <1243706689.64.0.142857875696.issue5922@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Indeed, I called it nitpicking in the first place. I think it would be a
micro-improvement, but still an improvement :)

Thanks for replying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5922>
_______________________________________

From report at bugs.python.org  Sat May 30 21:07:05 2009
From: report at bugs.python.org (mike bayer)
Date: Sat, 30 May 2009 19:07:05 +0000
Subject: [issue998998] pickle bug - recursively memoizing class?
Message-ID: <1243710425.42.0.982027672561.issue998998@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

im noticing my test case seems to work fine in py 3.0.1.   haven't
tested 2.6.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue998998>
_______________________________________

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: [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:08:07 2009
From: report at bugs.python.org (mike bayer)
Date: Sat, 30 May 2009 20:08:07 +0000
Subject: [issue6149] WeakValueDictionary constructor ported to Python 3.0
	incorrectly
In-Reply-To: <1243714064.27.0.0793186526424.issue6149@psf.upfronthosting.co.za>
Message-ID: <1243714087.43.0.655445871598.issue6149@psf.upfronthosting.co.za>


Changes by mike bayer <mike_mp at zzzcomputing.com>:


----------
components: +Library (Lib)
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6149>
_______________________________________

From report at bugs.python.org  Sat May 30 22:38:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 20:38:02 +0000
Subject: [issue6149] WeakValueDictionary constructor ported to Python 3.0
	incorrectly
In-Reply-To: <1243714064.27.0.0793186526424.issue6149@psf.upfronthosting.co.za>
Message-ID: <1243715882.15.0.0606333753607.issue6149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch for 3.1.

----------
keywords: +patch
nosy: +pitrou
priority:  -> high
stage:  -> patch review
versions: +Python 3.1 -Python 3.0
Added file: http://bugs.python.org/file14121/issue6149.patch

_______________________________________
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: [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  Sat May 30 22:46:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 May 2009 20:46:21 +0000
Subject: [issue6150] test_unicode fails in wide unicode build
In-Reply-To: <1243716302.52.0.46548419038.issue6150@psf.upfronthosting.co.za>
Message-ID: <1243716381.22.0.113070390877.issue6150@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> loewis
nosy: +loewis
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6150>
_______________________________________

From report at bugs.python.org  Sat May 30 22:46:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 May 2009 20:46:28 +0000
Subject: [issue6150] test_unicode fails in wide unicode build
In-Reply-To: <1243716302.52.0.46548419038.issue6150@psf.upfronthosting.co.za>
Message-ID: <1243716388.36.0.885282371307.issue6150@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6150>
_______________________________________

From report at bugs.python.org  Sat May 30 23:00:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 21:00:11 +0000
Subject: [issue5330] profile and cProfile do not report C functions called
	with keyword arguments
In-Reply-To: <1235135420.93.0.617344393794.issue5330@psf.upfronthosting.co.za>
Message-ID: <1243717211.92.0.810651639158.issue5330@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch, with test.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file14122/issue5330.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5330>
_______________________________________

From report at bugs.python.org  Sat May 30 23:05:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 21:05:30 +0000
Subject: [issue6149] WeakValueDictionary constructor ported to Python 3.0
	incorrectly
In-Reply-To: <1243714064.27.0.0793186526424.issue6149@psf.upfronthosting.co.za>
Message-ID: <1243717530.55.0.837174399155.issue6149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r73063. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6149>
_______________________________________

From report at bugs.python.org  Sat May 30 23:11:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 21:11:42 +0000
Subject: [issue4618] print_function and unicode_literals don't work together
In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za>
Message-ID: <1243717902.98.0.833789846723.issue4618@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> high
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4618>
_______________________________________

From report at bugs.python.org  Sat May 30 23:30:43 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 30 May 2009 21:30:43 +0000
Subject: [issue6127] Unexpected universal newline behavior (newline
	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1243719043.52.0.390568647234.issue6127@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I checked out the latest code from /branches/release26-maint and
compiled it.  Indeed the problem still exists.

Python 2.6.2+ (release26-maint:73061M, May 30 2009, 16:57:28) [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'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6127>
_______________________________________

From report at bugs.python.org  Sat May 30 23:44:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 21:44:40 +0000
Subject: [issue5330] profile and cProfile do not report C functions called
	with keyword arguments
In-Reply-To: <1235135420.93.0.617344393794.issue5330@psf.upfronthosting.co.za>
Message-ID: <1243719880.76.0.540457665899.issue5330@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r73064, r73065, r73066, r73067. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5330>
_______________________________________

From report at bugs.python.org  Sun May 31 00:41:12 2009
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 30 May 2009 22:41:12 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243723272.11.0.154600236805.issue1943@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

There were a number of patches to support sharing of data between 
unicode objects.  (By Larry Hastings?)  They were rejected because (a)  
they were complicated, and (b)  it was possible to provoke pathological 
memory retention.

----------
nosy: +jimjjewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sun May 31 00:47:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 May 2009 22:47:58 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243723272.11.0.154600236805.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243723809.16867.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There were a number of patches to support sharing of data between 
> unicode objects.  (By Larry Hastings?)  They were rejected because (a)  
> they were complicated, and (b)  it was possible to provoke pathological 
> memory retention.

Yes, it's the "lazy strings" patches by Larry Hastings (it was for str,
not unicode, though). Issues are #1590352 and #1569040 (and perhaps
others).

In any case, as I said, it is easy to switch back to the old
representation, so I don't think it is an argument to block this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Sun May 31 01:03:46 2009
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 30 May 2009 23:03:46 +0000
Subject: [issue6094] Python fails to build with Subversion 1.7
In-Reply-To: <1243102798.53.0.847495660834.issue6094@psf.upfronthosting.co.za>
Message-ID: <1243724626.61.0.227667022063.issue6094@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

Would this patch mean that users of pre-1.7 subversion would get build 
failures?  Is it possible to support both forms of wording?

----------
nosy: +jimjjewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6094>
_______________________________________

From report at bugs.python.org  Sun May 31 01:11:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 May 2009 23:11:12 +0000
Subject: [issue6094] Python fails to build with Subversion 1.7
In-Reply-To: <1243724626.61.0.227667022063.issue6094@psf.upfronthosting.co.za>
Message-ID: <1afaf6160905301611h40094e3ate257c766d3f6ef5f@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/5/30 Jim Jewett <report at bugs.python.org>:
>
> Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:
>
> Would this patch mean that users of pre-1.7 subversion would get build
> failures? ?Is it possible to support both forms of wording?

Yes, and it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6094>
_______________________________________

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: [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 02:09:45 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 31 May 2009 00:09:45 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243728585.59.0.943297098126.issue6137@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

If I understood correctly, #3675 is about making pickle data generated
by Python 3 readable by Python 2. However, this issue is about
compatibility in the other direction?i.e., making Python 2 pickles
readable by Python 3, which is easier.

I have a patch that make Unpickler translates the old names to the new
ones at runtime. The only thing missing in the patch is the unit tests
since I am not sure this should be tested. I am thinking using the
approach Collin Winter used for his compatibility tests in #5665.
However, his approach requires bidirectional pickle compatibility
between Python 2 and 3, which we don't have.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file14124/compat_pickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Sun May 31 02:15:56 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 31 May 2009 00:15:56 +0000
Subject: [issue956303] Update pickle docs to describe format of persistent IDs
Message-ID: <1243728956.02.0.94122979208.issue956303@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The updated documentation for pickle for Python 3 describes the
requirement that persistent IDs should be alphanumeric strings when
protocol 0 is used.

http://docs.python.org/3.0/library/pickle.html#persistence-of-external-objects

Closing as fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue956303>
_______________________________________

From report at bugs.python.org  Sun May 31 03:11:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 01:11:49 +0000
Subject: [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 03:13:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 01:13:10 +0000
Subject: [issue6152] Parellel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243732390.46.0.686001242512.issue6152@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed 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 03:13:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 01:13:30 +0000
Subject: [issue6152] Parellel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243732410.14.0.256885572595.issue6152@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file14126/regrtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6152>
_______________________________________

From report at bugs.python.org  Sun May 31 03:32:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 01:32:37 +0000
Subject: [issue6152] Parallel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243733557.86.0.983010278592.issue6152@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: Parellel regression testing -> Parallel regression testing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6152>
_______________________________________

From report at bugs.python.org  Sun May 31 06:46:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 May 2009 04:46:50 +0000
Subject: [issue6151] Make PyDescr_COMMON conform to standard C
In-Reply-To: <1243725945.44.0.74609777501.issue6151@psf.upfronthosting.co.za>
Message-ID: <1243745210.25.0.988091484108.issue6151@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine in principle. I believe many of the macro
applications are unnecessary, because the type of the variables being
accessed is already PyDescrObject.

Not sure whether this can be applied to 3.1 still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6151>
_______________________________________

From report at bugs.python.org  Sun May 31 07:14:46 2009
From: report at bugs.python.org (Winston Ewert)
Date: Sun, 31 May 2009 05:14:46 +0000
Subject: [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 07:44:29 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 31 May 2009 05:44:29 +0000
Subject: [issue4618] print_function and unicode_literals don't work together
In-Reply-To: <1228915146.01.0.235938679842.issue4618@psf.upfronthosting.co.za>
Message-ID: <1243748668.73.0.532876567298.issue4618@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4618>
_______________________________________

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: [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 13:20:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 11:20:48 +0000
Subject: [issue6152] Parallel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243768848.23.0.138614156375.issue6152@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file14126/regrtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6152>
_______________________________________

From report at bugs.python.org  Sun May 31 13:21:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 11:21:08 +0000
Subject: [issue6152] Parallel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243768868.92.0.486941761364.issue6152@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch, taking into account the '-u' option.

----------
Added file: http://bugs.python.org/file14127/regrtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6152>
_______________________________________

From report at bugs.python.org  Sun May 31 16:22:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 14:22:20 +0000
Subject: [issue6152] Parallel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1243779740.02.0.397566311379.issue6152@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r73072, waiting for the 3.1 release to merge in py3k.

----------
assignee:  -> pitrou
resolution:  -> accepted
stage: patch review -> commit review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6152>
_______________________________________

From report at bugs.python.org  Sun May 31 16:35:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 May 2009 14:35:27 +0000
Subject: [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: <1243780527.28.0.224669673927.issue6154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Sorry to be pulling you into this, but would you see if this patch fixes
your woes?

----------
keywords: +patch
Added file: http://bugs.python.org/file14128/locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________

From report at bugs.python.org  Sun May 31 17:10:42 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 May 2009 15:10:42 +0000
Subject: [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: <1243782642.67.0.326197353566.issue6154@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Benjamin, configure script check for function textdomain in libintl.

----------
nosy: +rpetrov

_______________________________________
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: [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: [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 18:42:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 May 2009 16:42:07 +0000
Subject: [issue6155] "logging" example uses unavailable cPickle module
In-Reply-To: <1243786839.04.0.100473713969.issue6155@psf.upfronthosting.co.za>
Message-ID: <1243788127.01.0.911493319021.issue6155@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r73075.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6155>
_______________________________________

From report at bugs.python.org  Sun May 31 20:22:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 18:22:06 +0000
Subject: [issue6153] email parsing - Rare Failure
In-Reply-To: <1243746885.91.0.189696323445.issue6153@psf.upfronthosting.co.za>
Message-ID: <1243794126.03.0.113287544244.issue6153@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6153>
_______________________________________

From report at bugs.python.org  Sun May 31 20:28:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 May 2009 18:28:32 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243794512.79.0.664452095348.issue6137@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If I understood correctly, #3675 is about making pickle data generated
> by Python 3 readable by Python 2.

Only if a protocol <= 2 is specified. Therefore it seems it's "only" a
matter of translating module names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Sun May 31 21:04:21 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sun, 31 May 2009 19:04:21 +0000
Subject: [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: <1243796661.32.0.685394242946.issue6154@psf.upfronthosting.co.za>


Erick Tryzelaar <idadesub at users.sourceforge.net> added the comment:

Benjamin, I just applied that patch but I still got the same error:

		/usr/bin/libtool -o Python.framework/Versions/3.1/Python 
-dynamic  libpython3.1.a \
			 -lSystem -lSystemStubs -arch_only i386 -
install_name 
/opt/local/Library/Frameworks/Python.framework/Versions/3.1/Python -
compatibility_version 3.1 -current_version 3.1 -framework 
CoreFoundation;\
	fi
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
/usr/bin/libtool: internal link edit command failed

----------
nosy: +erickt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________

From report at bugs.python.org  Sun May 31 21:36:26 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 May 2009 19:36:26 +0000
Subject: [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: <1243798586.03.0.141413977711.issue6154@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Still fails because you are now no longer compiling against
CoreFoundation. Probably need both CoreFoundation and intl:

gcc -L/Users/brett/usr/lib -L/Users/brett/.local/lib -L/unix/lib
-L/unix/macports/lib -L/Developer/usr/lib -lintl -o python.exe \
			Modules/python.o \
			libpython3.1.a -ldl      
Undefined symbols:
  "_CFStringConvertEncodingToIANACharSetName", referenced from:
      _mac_getscript in libpython3.1.a(_localemodule.o)
  "_CFStringGetSystemEncoding", referenced from:
      _mac_getscript in libpython3.1.a(_localemodule.o)
  "_CFStringGetCStringPtr", referenced from:
      _mac_getscript in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________

From report at bugs.python.org  Sun May 31 21:59:01 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 31 May 2009 19:59:01 +0000
Subject: [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243799941.47.0.428289135309.issue6156@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I agree that it's a bug.

A workaround is r'([xy])(?:\s{0,65534}\1)+'. A repeat of 65535 is
treated as unlimited (but no warning is given).

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6156>
_______________________________________

From report at bugs.python.org  Sun May 31 22:05:49 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 May 2009 20:05:49 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1243800349.44.0.143857367671.issue3848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed (with fix to doc patch) to trunk in r73077, 26 in r73078, py3k
in r73079, and 30 in r73081.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

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: [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>
_______________________________________

From report at bugs.python.org  Sun May 31 22:39:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 31 May 2009 20:39:13 +0000
Subject: [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: <1243802353.92.0.743930943611.issue6154@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't see Brett's failure with a straight './configure && make' issued 
from the top directory of a clean svn py3k checkout (r73082), but I do 
see it with:

CC="gcc -I/opt/local/include -L/opt/local/lib" ./configure && make

I'm on OS X 10.5.7, and have a MacPorts version of libintl installed as 
/opt/local/lib/libintl.dylib.  The configure script correctly defines 
HAVE_LIBINTL_H to 1, and later detects that libintl *is* needed, and 
consequently defines WITH_LIBINTL, but then as far as I can tell does 
nothing further with that define.

In the patch (locale_fix.patch), I don't understand this bit:

+                if test $have_intl
+                then
+		   LINKFORSHARED="$extra_undefs -lintl"
+                else
+                   LINKFORSHARED="$extra_undefs -framework 
CoreFoundation"
+                fi

Why is the "-framework CoreFoundation" bit not included if $have_intl is 
set?  When I apply your patch and rebuild as above I get a different 
failure:

gcc -I/opt/local/include -L/opt/local/lib  -lintl -o python.exe \
			Modules/python.o \
			libpython3.1.a -ldl      
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)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1

But if I apply your patch and also add the "-framework CoreFoundation" 
bit back in, then the build succeeds.

Also note that there's already a check for whether libintl is needed
in configure.in, at around line 1820:

# check if we need libintl for locale functions
AC_CHECK_LIB(intl, textdomain,
	AC_DEFINE(WITH_LIBINTL, 1,
	[Define to 1 if libintl is needed for locale functions.]))

Probably we don't need both checks.

And a nitpick:  it looks as though the tabbing in your patch isn't 
consistent with the surrounding configure code.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________

From report at bugs.python.org  Sun May 31 22:47:37 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 31 May 2009 20:47:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1243802857.14.0.722662537346.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've completed another draft patch.  This new one separates the
implementation of lstat and stat for windows, the latter which traverses
symlinks for the target.

I've tested this.  It compiles and runs under Windows Vista.  It works
correctly with file symlinks.  It fails to correctly detect that a
directory symlink is a symlink.  This is due to the fact that Windows
symlinks can also be directories, and the os.islink which calls
stat.S_ISLNK doesn't mask out the directory bit when checking for
symlinkness.

I see a few possible solutions:

1) Change S_ISLNK to mask of the directory bit when in Windows.
2) Change os.islink to perform a different test when in Windows.
3) Change the implementation of win32_lstat and win32_lstat_w to erase
the directory bit when the path is a link.

At first glance, option 3 seems the most promising, but it hides the
fact that Windows cares about the directoryness of a symlink.  It is
possible, for example, to have a "directory symlink" referring to a file
object in the file system.  S_ISDIR would be true for the symlink and
false for the target.

I think I'm going to implement approach 3 in a subsequent patch unless I
hear objections.

I also still need to implement Martin's two suggestions (release
kernel32 handle, inline functions).

But I wanted to share this patch for any suggestions.

----------
Added file: http://bugs.python.org/file14130/windows symlink draft 4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun May 31 23:15:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2009 21:15:50 +0000
Subject: [issue5675] string module requires bytes type for maketrans,
	but calling method on regular string does not
In-Reply-To: <1238716476.0.0.609350611694.issue5675@psf.upfronthosting.co.za>
Message-ID: <1243804550.51.0.62342151565.issue5675@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The bytearray.maketrans() method isn't documented yet.

----------
components: +Documentation -Interpreter Core
nosy: +rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5675>
_______________________________________

From report at bugs.python.org  Sun May 31 23:29:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 May 2009 21:29:19 +0000
Subject: [issue2443] uninitialized access to va_list
In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za>
Message-ID: <1243805359.66.0.574462838735.issue2443@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Reducing the priority and updating the target releases, since from the
discussion there doesn't appear to be a bug here.

----------
nosy: +r.david.murray
priority: critical -> normal
stage:  -> commit review
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2443>
_______________________________________

From report at bugs.python.org  Sun May 31 23:39:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 May 2009 21:39:04 +0000
Subject: [issue5675] string module requires bytes type for maketrans,
	but calling method on regular string does not
In-Reply-To: <1238716476.0.0.609350611694.issue5675@psf.upfronthosting.co.za>
Message-ID: <1243805944.74.0.734768557554.issue5675@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed in r73086.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5675>
_______________________________________

From report at bugs.python.org  Sun May 31 23:56:33 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 31 May 2009 21:56:33 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243806993.03.0.622470209458.issue2919@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Attached is *an* attempt to combine the old profile/cProfile modules into a single 
one called profile.  Only the C and Python source and test files are included, not 
any documentation files.  More details are in the README file, copied below.

Hopefully, this is useful.

/Jean Brouwers


These are the modified files to replace the old profile module with the fast cProfile 
one and rename the latter.  A complete list and description follow.


./README

./profileNEW/setup.py
./profileNEW/Lib/profile.py
./profileNEW/Lib/test/profilee.py
./profileNEW/Lib/test/test_profile.py
./profileNEW/Modules/_profile.c

./profilePy3k/setup.py
./profilePy3k/Lib/profile.py
./profilePy3k/Lib/test/profilee.py
./profilePy3k/Lib/test/test_cprofile.py
./profilePy3k/Lib/test/test_profile.py
./profilePy3k/Modules/_lsprof.c

./diff_-u_profilePy3k_Modules_lsprof.c_profileNEW_Modules_profile.c.txt
./diff_-ur_profilePy3k_profileNEW.txt

./_profile_hires.c



Directory profileNEW contains all the source and test files in their corresponding 
directories.  Directory  profilePy3k contains the old, original files from the py3k 
trunk taken on May 31, 2009.

Basically, the old _lsprof.c file has been modified and renamed to _profile.c.  Both 
old test_profile.py and test_cprofile.py files have been combined into a single new 
file test_profile.py.

The file  diff_-ur_profilePy3k_profileNEW.txt  contains the forward diffences between 
all the new and orginal files.

File diff_-u_profilePy3k_Modules_lsprof.c_profileNEW_Modules_profile.c.txt contains 
just the differences between the old  _lsprof.c and new  _profile.c files.

Lastly, for your consideration, file _profile_hires.c is the new _profile.c file 
enhanced to use a high resolution timer, see <http://bugs.python.org/issue2281>.  
This file would replace the _profile.c file in the profileNEW/Modules directory.



The new files and tests were installed in a Python 3.0.1 build and compiled and 
tested on MacOS X 10.4.11 Tiger (Intel).  The patches from issue 5330 were also 
installed in this build, see <http://bugs.python.org/issue5330>.  All tests passed 
after regenerating the expected results

% python.exe Lib/test/test_profile.py -r
Regenerating Lib/test/test_profile.py...

% python.exe Lib/test/test_profile.py 
test_bad_counter_during_dealloc (__main__.ProfileTest) ... ok
test_calling_conventions (__main__.ProfileTest) ... ok
test_profile (__main__.ProfileTest) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.017s

OK

----------
nosy: +MrJean1
Added file: http://bugs.python.org/file14131/profile_module.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________