From report at bugs.python.org  Tue Sep  1 00:20:14 2009
From: report at bugs.python.org (Seamus O'Shea)
Date: Mon, 31 Aug 2009 22:20:14 +0000
Subject: [issue6812] Snow Leopard python program fails because
	_PyType_Modified is missing from python framework
In-Reply-To: <1251757214.1.0.925595604794.issue6812@psf.upfronthosting.co.za>
Message-ID: <1251757214.1.0.925595604794.issue6812@psf.upfronthosting.co.za>


New submission from Seamus O'Shea <oshea at uleth.ca>:

Attempts to compile a simple example using XCode 3.2 (Xcode IDE: 1610.0, 
Xcode Core: 1608.0, ToolSupport: 1591.0)under Snow Leopard fail with 
error message 
Traceback (most recent call last):
  File "/Users/seamus/Science/xcode exploration/Objc-
programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/ma
in.py", line 10, in <module>
    import objc
  File 
"/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib
/python/PyObjC/objc/__init__.py", line 22, in <module>
    _update()
  File 
"/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib
/python/PyObjC/objc/__init__.py", line 19, in _update
    import _objc
ImportError: 
dlopen(/System/Library/Frameworks/Python.framework/Versions/Current/Extr
as/lib/python/PyObjC/objc/_objc.so, 2): Symbol not found: 
_PyType_Modified
  Referenced from: 
/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/
python/PyObjC/objc/_objc.so
  Expected in: flat namespace
 in 
/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/
python/PyObjC/objc/_objc.so
2009-08-31 08:31:23.534 First_PyObjC[4072:a0f] *** Terminating app due 
to uncaught exception 'NSInternalInconsistencyException', reason: 
'/Users/seamus/Science/xcode exploration/Objc-
programs/First_PyObjC/main.m:46 main() PyRun_SimpleFile failed with file 
'/Users/seamus/Science/xcode exploration/Objc-
programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/ma
in.py'.  See console for errors.'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x90a1858a __raiseError 
+ 410
	1   libobjc.A.dylib                     0x9309cf49 
objc_exception_throw + 56
	2   CoreFoundation                      0x90a182b8 +[NSException 
raise:format:arguments:] + 136
	3   CoreFoundation                      0x90a1822a +[NSException 
raise:format:] + 58
	4   First_PyObjC                        0x00002bc2 main + 1084
	5   First_PyObjC                        0x0000275a start + 54
)
sharedlibrary apply-load-rules all

The Current Version in the system library is 2.6.

Any suggestions?

----------
assignee: ronaldoussoren
components: Macintosh
messages: 92117
nosy: ronaldoussoren, soshea
severity: normal
status: open
title: Snow Leopard python program fails because _PyType_Modified is missing from python framework
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  1 04:59:45 2009
From: report at bugs.python.org (Phil Pennock)
Date: Tue, 01 Sep 2009 02:59:45 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1251773985.13.0.165054194534.issue5639@psf.upfronthosting.co.za>


Phil Pennock <python-dev at spodhuis.org> added the comment:

(Sorry for dropping this, lost available time)

I see your point.  OTOH, use of SNI needs to be something that can be 
disabled and people need to be able to connect to host A while supplying 
host B, not necessarily using IP addresses for the specificity.  Use-
case example: someone has a service "www" hosted on ["www-1", "www-2", 
"www-3"].  They have an SSL certificate for "www" and they want to have 
a health-checker which probes for "working service, all certs valid and 
not about to expire".

Unless s.connect() gains a keep_original_hostname=False option (?), this 
is hard to do.

Then there's the principle of least surprise -- while it would be nice 
to get SNI working automatically for everyone, it's still plausible that 
amongst the various TLS servers out there are some which break horribly 
for SNI and upgrading Python shouldn't break the tools in use.

So I tend towards favouring "make use of the newer, less well tested, 
protocol feature something that has to be explicitly enabled", even if 
it adds a line to boilerplate -- if SNI ever takes over the world (as 
Host: headers in HTTP have) then it can be defaulted on in future 
perhaps?

In which case, if the default is to change, the API should be sorted 
now, so perhaps connect() should take an override_server_hostname=False 
flag, which will make it pass the connect() hostname parameter instead 
of self.server_hostname in the call to _ssl.sslwrap()?  With checking 
for an IP address?

----------

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

From report at bugs.python.org  Tue Sep  1 05:00:12 2009
From: report at bugs.python.org (Miles Kaufmann)
Date: Tue, 01 Sep 2009 03:00:12 +0000
Subject: [issue5468] urlencode does not handle "bytes",
	and could easily handle alternate encodings
In-Reply-To: <1236696316.6.0.478633045289.issue5468@psf.upfronthosting.co.za>
Message-ID: <1251774012.31.0.0762243587453.issue5468@psf.upfronthosting.co.za>


Changes by Miles Kaufmann <milesck at umich.edu>:


Removed file: http://bugs.python.org/file14796/urllib_parse.py3k.patch

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

From report at bugs.python.org  Tue Sep  1 06:05:06 2009
From: report at bugs.python.org (Daniel Black)
Date: Tue, 01 Sep 2009 04:05:06 +0000
Subject: [issue6813] update format() documentation and tutorial
In-Reply-To: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>
Message-ID: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>


New submission from Daniel Black <daniel at cacert.org>:

Release notes show the use of '{}'.format('this') and the attached patch
updates this to be the default example in the tutorial. Library
references are updated to show field_name as optional and a few examples
are added.

Relates to the improvements from issue 5237.

----------
assignee: georg.brandl
components: Documentation
files: documentation-str-format.patch
keywords: patch
messages: 92119
nosy: georg.brandl, grooverdan
severity: normal
status: open
title: update format() documentation and tutorial
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14812/documentation-str-format.patch

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

From report at bugs.python.org  Tue Sep  1 08:11:33 2009
From: report at bugs.python.org (Daniel Black)
Date: Tue, 01 Sep 2009 06:11:33 +0000
Subject: [issue6814] xrange removal from documentation
In-Reply-To: <1251785493.22.0.615787122176.issue6814@psf.upfronthosting.co.za>
Message-ID: <1251785493.22.0.615787122176.issue6814@psf.upfronthosting.co.za>


New submission from Daniel Black <daniel at cacert.org>:

xrange still exists in bits of documentation here and there.

patch fixes it.

----------
assignee: georg.brandl
components: Documentation
files: xrange-doco.patch
keywords: patch
messages: 92120
nosy: georg.brandl, grooverdan
severity: normal
status: open
title: xrange removal from documentation
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14813/xrange-doco.patch

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

From report at bugs.python.org  Tue Sep  1 09:34:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 07:34:48 +0000
Subject: [issue6814] xrange removal from documentation
In-Reply-To: <1251785493.22.0.615787122176.issue6814@psf.upfronthosting.co.za>
Message-ID: <1251790488.98.0.479805042187.issue6814@psf.upfronthosting.co.za>


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

Thanks, applied in r74613 (and will be merged to 3.1 branch soon).

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

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

From report at bugs.python.org  Tue Sep  1 09:43:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 07:43:06 +0000
Subject: [issue6813] update format() documentation and tutorial
In-Reply-To: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>
Message-ID: <1251790986.51.0.700458635515.issue6813@psf.upfronthosting.co.za>


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

Thanks, committed as r74614 (trunk), r74615 (3k).

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

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

From report at bugs.python.org  Tue Sep  1 09:46:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 07:46:58 +0000
Subject: [issue6808] python 3.1 documentation tutorial classes
In-Reply-To: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>
Message-ID: <1251791218.15.0.100200316326.issue6808@psf.upfronthosting.co.za>


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

Fixed 1.) in r74616.  The "instances of C" is already correct in the
sources.

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

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

From report at bugs.python.org  Tue Sep  1 09:51:17 2009
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Tue, 01 Sep 2009 07:51:17 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>


New submission from Alexandr Zamaraev <shura_zam at users.sourceforge.net>:

OS Windows Vista Home Basic Ru + sp2
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32

Simple code to crach (file expandvars_bug.py):
[code]
# -*- coding: cp1251 -*-
import os.path

var = r'C:\????\Microsoft'
print os.path.expandvars(var)
print os.path.expandvars(unicode(var))
[/code]
Console session:
[code]
C:\????\Microsoft
Traceback (most recent call last):
  File "C:\Lang\test\python\expandvars_bug.py", line 6, in <module>
    print os.path.expandvars(unicode(var))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 3:
ordinal
not in range(128)
[/code]

----------
components: Unicode
messages: 92124
nosy: shura_zam
severity: normal
status: open
title: UnicodeDecodeError in os.path.expandvars
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  1 09:51:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 07:51:31 +0000
Subject: [issue6798] Argument for sys.settrace() callbacks documented
	incorrectly
In-Reply-To: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>
Message-ID: <1251791491.25.0.895983146239.issue6798@psf.upfronthosting.co.za>


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

It certainly seems to be implemented this way in ceval.c. I don't know
if the docs describe the implementation intent better, but I'd say that
this is then such a minor issue that just documenting the actual
behavior is the best thing to do.

----------

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

From report at bugs.python.org  Tue Sep  1 09:54:01 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 07:54:01 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251791641.88.0.317312605923.issue6765@psf.upfronthosting.co.za>


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

Okay, I made changes along Terry' suggestions in r74617.

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

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

From report at bugs.python.org  Tue Sep  1 09:55:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Sep 2009 07:55:20 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1251791720.61.0.543044433103.issue6815@psf.upfronthosting.co.za>


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

If you don't specify the encoding, unicode() will decode 'var' using the
default ascii codec and it will fail if 'var' contains non-ascii
characters. You should use var.decode(encoding) instead.

The fact that the first print is not displayed correctly is probably due
to the limitation of the Windows terminal.

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

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

From report at bugs.python.org  Tue Sep  1 09:59:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 07:59:25 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1251791965.61.0.663582536601.issue6239@psf.upfronthosting.co.za>


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

Assigning back to Thomas for commit.

----------
assignee: benjamin.peterson -> theller
resolution:  -> accepted

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

From report at bugs.python.org  Tue Sep  1 10:01:01 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 08:01:01 +0000
Subject: [issue6810] add link to the documentation of signal.signal
In-Reply-To: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>
Message-ID: <1251792061.77.0.791117870417.issue6810@psf.upfronthosting.co.za>


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

I added a link and an anchor in r74618.

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

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

From report at bugs.python.org  Tue Sep  1 10:02:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 08:02:12 +0000
Subject: [issue6754] Non-existent member 'nb_inplace_divide' in PyNumberMethods
In-Reply-To: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>
Message-ID: <1251792132.36.0.540638261455.issue6754@psf.upfronthosting.co.za>


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

Thanks, fixed in r74619.

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

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

From report at bugs.python.org  Tue Sep  1 10:03:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 08:03:39 +0000
Subject: [issue6732] PyInit_shoddy() in shoddy.c does not return anything on
	success
In-Reply-To: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>
Message-ID: <1251792219.86.0.0587744078128.issue6732@psf.upfronthosting.co.za>


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

Thanks, fixed in r74620.

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

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

From report at bugs.python.org  Tue Sep  1 10:06:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Sep 2009 08:06:10 +0000
Subject: [issue6638] optparse parse_args argument references wrong
In-Reply-To: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>
Message-ID: <1251792370.15.0.376378243888.issue6638@psf.upfronthosting.co.za>


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

Thanks, fixed in r74621.

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

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

From report at bugs.python.org  Tue Sep  1 10:28:14 2009
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Tue, 01 Sep 2009 08:28:14 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1251793694.69.0.996186606427.issue6815@psf.upfronthosting.co.za>


Alexandr Zamaraev <shura_zam at users.sourceforge.net> added the comment:

Sorry.
First code is:
var = ${APPDATA}\Microsoft\Windows\Start Menu

In my windows 
F:\Lang\sf.net\svn\appupdater>echo %APPDATA%
C:\Users\??????\AppData\Roaming

----------

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

From report at bugs.python.org  Tue Sep  1 10:34:01 2009
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Tue, 01 Sep 2009 08:34:01 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1251794041.68.0.442801428154.issue6815@psf.upfronthosting.co.za>


Alexandr Zamaraev <shura_zam at users.sourceforge.net> added the comment:

All code:
[code]
# -*- coding: cp1251 -*-
import os.path

var = r'${APPDATA}\Microsoft\Windows\Start Menu'
print os.path.expandvars(var)
print os.path.expandvars(unicode(var, 'cp1251'))
[/code]
Console session:
[code]
C:\Users\??????\AppData\Roaming\Microsoft\Windows\Start Menu
Traceback (most recent call last):
  File "C:\Lang\test\python\expandvars_bug.py", line 6, in <module>
    print os.path.expandvars(unicode(var, 'cp1251'))
  File "C:\Lang\Python\26\lib\ntpath.py", line 388, in expandvars
    res = res + c
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcb in position 9:
ordinal not in range(128)
[/code]

----------

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

From report at bugs.python.org  Tue Sep  1 10:50:04 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Sep 2009 08:50:04 +0000
Subject: [issue6813] update format() documentation and tutorial
In-Reply-To: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>
Message-ID: <1251795004.38.0.9157061406.issue6813@psf.upfronthosting.co.za>


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

2.7 does not support the !a conversion specifier. It's only available in
3.1 and above.

It's because ascii() is a 3.x only builtin.

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

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

From report at bugs.python.org  Tue Sep  1 10:51:59 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Sep 2009 08:51:59 +0000
Subject: [issue6813] update format() documentation and tutorial
In-Reply-To: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>
Message-ID: <1251795119.72.0.0175652143135.issue6813@psf.upfronthosting.co.za>


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

Never mind, I see that you didn't add the !a docs to trunk.

----------

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

From report at bugs.python.org  Tue Sep  1 11:12:44 2009
From: report at bugs.python.org (Daniel Black)
Date: Tue, 01 Sep 2009 09:12:44 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1251796364.78.0.495649374232.issue5885@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

This is a slightly crude module version. The speedups were only 10%

Python 3.2a0 (py3k:74612M, Sep  1 2009, 18:11:58)                       
[GCC 4.3.2] on linux2  

Using the same test from Wang Chun:
before:
uuid1(1000000)
101.759 microseconds

after:
uuid1(1000000)
91.663 microseconds

The delays are clearly in the _byte array copying as indicated by the
test below:
>>> import sys, time, uuid
>>> def uu(n):
...      t = time.time()
...      for x in range(n):
...         uuid._uuid_generate_time_fast()
...      print('%.3f microseconds' % ((time.time() - t) * 1000000.0 / n))
...
[72265 refs]
>>> uu(1000000)
13.157 microseconds
[72267 refs]

I would expect fixing this for the ctypes version would have a similar
speedup.

----------
keywords: +patch
nosy: +grooverdan
Added file: http://bugs.python.org/file14814/uuid_c_module.patch

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

From report at bugs.python.org  Tue Sep  1 11:29:32 2009
From: report at bugs.python.org (Daniel Black)
Date: Tue, 01 Sep 2009 09:29:32 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1251797372.23.0.743416080796.issue5885@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

to prove it a bit more - ctype benchmark
>>> import ctypes, ctypes.util
>>> def uu1(n):
...      t = time.time()
...      _buffer = ctypes.create_string_buffer(16)
...      for x in range(n):
...         uuid._uuid_generate_time(_buffer)
...      print('%.3f microseconds' % ((time.time() - t) * 1000000.0 / n))
...
>>> uu1(1000000)
15.819 microseconds

----------

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

From report at bugs.python.org  Tue Sep  1 11:58:52 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Sep 2009 09:58:52 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1251799132.09.0.108811016501.issue3724@psf.upfronthosting.co.za>


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

The docs were patched in r74617 to (re)close #6765.
This included something similar to the OP's math_doc.patch.

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

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

From report at bugs.python.org  Tue Sep  1 12:56:39 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Sep 2009 10:56:39 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, the runpy._run_module_as_main() function allows a launch
script to mimic Python's -m switch fairly well.

This RFE suggests making it possible to mimic other command line
behaviour of the CPython interpreter in a documented fashion:

run_module_as_main - document and make public the existing
_run_module_as_main function (exposes -m style functionality)

run_path_as_main - accept a filesystem path and execute it as per the
command line rules for executing named scripts, zipfiles and directories
(exposes normal script execution functionality)

run_file_as_main - accept a file-like object and execute it as per the
command line rules for executing stdin (exposes '-' style functionality)

run_code_as_main - accept a string or code object and execute it
(exposes -c style functionality)

The runpy module would also be updated to expose these via its command
line to ensure they achieve their stated goal of allowing a launch
script to mimic the native interpreter behaviour. Due to the legacy of
implementing -m style execution by default, the module command line will
expose filesystem path execution through a '-f' switch.

----------
messages: 92140
nosy: ncoghlan
severity: normal
status: open
title: Provide CPython command line functionality via runpy module
type: feature request

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

From report at bugs.python.org  Tue Sep  1 12:56:57 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Sep 2009 10:56:57 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1251802617.68.0.498854885023.issue6816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan
versions: +Python 3.2

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

From report at bugs.python.org  Tue Sep  1 13:08:51 2009
From: report at bugs.python.org (Chris Withers)
Date: Tue, 01 Sep 2009 11:08:51 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1251803331.01.0.553221766258.issue6816@psf.upfronthosting.co.za>


Changes by Chris Withers <chris at simplistix.co.uk>:


----------
nosy: +cjw296

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

From report at bugs.python.org  Tue Sep  1 13:23:47 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Sep 2009 11:23:47 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1251804227.19.0.931894943349.issue6816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Tue Sep  1 17:38:06 2009
From: report at bugs.python.org (Dan)
Date: Tue, 01 Sep 2009 15:38:06 +0000
Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1251819486.0.0.702229631148.issue4683@psf.upfronthosting.co.za>


Dan <daniel at ohuiginn.net> added the comment:

Attaching a patch. I don't have a test to go with it, except for the one
submitted with the bug report.

----------
keywords: +patch
Added file: http://bugs.python.org/file14815/nonce_count.diff

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

From report at bugs.python.org  Tue Sep  1 17:47:20 2009
From: report at bugs.python.org (itkach)
Date: Tue, 01 Sep 2009 15:47:20 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1251820040.25.0.309123659793.issue5689@psf.upfronthosting.co.za>


Changes by itkach <itkach at gmail.com>:


----------
nosy: +itkach

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

From report at bugs.python.org  Tue Sep  1 20:58:34 2009
From: report at bugs.python.org (segfault42)
Date: Tue, 01 Sep 2009 18:58:34 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1251831514.76.0.740568206252.issue6434@psf.upfronthosting.co.za>


segfault42 <brice.nahum at free.fr> added the comment:

still no one to help on this problem ? is someone has some idea ?

----------

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

From report at bugs.python.org  Tue Sep  1 23:58:41 2009
From: report at bugs.python.org (Boya Sun)
Date: Tue, 01 Sep 2009 21:58:41 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1251842321.0.0.900152162953.issue3139@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Although the bug is fixed, the following three code segments seems
suspicious in _codecsmodule.c in the latest revision 74624, and they are
similar to the bug described here:

(1)
escape_decode(PyObject *self,
	      PyObject *args)
{
    ...
    const char *data;
    ...
    if (!PyArg_ParseTuple(args, "s#|z:escape_decode",
			  &data, &size, &errors))
}

(2)
readbuffer_encode(PyObject *self,
		  PyObject *args)
{
    const char *data;
    ...
    if (!PyArg_ParseTuple(args, "s#|z:readbuffer_encode",
			  &data, &size, &errors))
    ...
}

(3)
charbuffer_encode(PyObject *self,
		  PyObject *args)
{
    const char *data;
    ...
    if (!PyArg_ParseTuple(args, "t#|z:charbuffer_encode",
			  &data, &size, &errors))
    ...
}

Firstly, "char *data;" have been replaced by "Py_buffer pbuf;" in many
procedures in this file in the bug fix, but these code did not;
Secondly, they uses "s#" or "t#" which should probably changed to "s*";

I could be wrong about it.  Does anyone have any opinions on the above
code? Are they really buggy or am I misunderstanding anything?

----------
nosy: +boya

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

From report at bugs.python.org  Wed Sep  2 00:34:54 2009
From: report at bugs.python.org (Boya Sun)
Date: Tue, 01 Sep 2009 22:34:54 +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: <1251844494.86.0.706350908586.issue5705@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Another potential bug discovered in posixmodule.c in the function
posix_lchown:

posix_lchown(PyObject *self, PyObject *args)
{
        ...
 	int uid, gid;
        ...
 	if (!PyArg_ParseTuple(args, "etii:lchown",
 	                      Py_FileSystemDefaultEncoding, &path,
 	                      &uid, &gid))
        ...
}

uid and gid could also cause over flow. Patch attached.

Hope some one can comment on the patch, thanks a lot!

----------
keywords: +patch
nosy: +boya
Added file: http://bugs.python.org/file14816/patch_5705.diff

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

From report at bugs.python.org  Wed Sep  2 00:46:55 2009
From: report at bugs.python.org (Boya Sun)
Date: Tue, 01 Sep 2009 22:46:55 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1251845215.49.0.948087421466.issue2722@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

This bug occurred in posix_getcwd() and is being fixed. 
Should the following code in posix_getcwdu() also be fixed the same way?

posix_getcwdu(PyObject *self, PyObject *noargs)
{
	char buf[1026];
        ...
#if defined(PYOS_OS2) && defined(PYCC_GCC)
	res = _getcwd2(buf, sizeof buf);
#else
	res = getcwd(buf, sizeof buf);
#endif
        ...
}

In my opinion, the fixed length buf should be discarded and instead
allocate memory to buf as needed (as the fix code in posix_getcwd()),
since getcwd() does not have a maximum anymore.

----------
nosy: +boya

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

From report at bugs.python.org  Wed Sep  2 00:59:05 2009
From: report at bugs.python.org (Boya Sun)
Date: Tue, 01 Sep 2009 22:59:05 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1251845945.8.0.663171060723.issue2620@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

In Python/pyarena.c:

block_new(size_t size)
{
	/* Allocate header and block as one unit.
	   ab_mem points just past header. */
	block *b = (block *)malloc(sizeof(block) + size);
        ...
}

Should a check for overflow of "size" also be performed before calling
"malloc"?

----------
nosy: +boya

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

From report at bugs.python.org  Wed Sep  2 01:31:30 2009
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 01 Sep 2009 23:31:30 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1251847890.0.0.139236054941.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14817/subprocess.rst.patch

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

From report at bugs.python.org  Wed Sep  2 01:44:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Sep 2009 23:44:14 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1251848654.56.0.538190899393.issue6434@psf.upfronthosting.co.za>


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

I did reproduce the problem, but I'm sorry I don't have the time to fix 
it. However, I will review any proposed patch.

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

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

From report at bugs.python.org  Wed Sep  2 02:54:22 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Sep 2009 00:54:22 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1251852862.41.0.0404727132442.issue3139@psf.upfronthosting.co.za>


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

In theory, yes. But it happens that the GIL is not released before the 
buffer is used.

----------

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

From report at bugs.python.org  Wed Sep  2 02:58:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Sep 2009 00:58:41 +0000
Subject: [issue6796] invalid print in tkinter\test\test_ttk\test_widgets.py
In-Reply-To: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>
Message-ID: <1251853121.6.0.894518619594.issue6796@psf.upfronthosting.co.za>


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

You have in your PYTHONPATH a script with the same name as a standard 
module, and this script uses the python2 syntax.
Please rename this script or change your PYTHONPATH.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Sep  2 03:38:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Sep 2009 01:38:14 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1251855494.92.0.64459166736.issue2722@psf.upfronthosting.co.za>


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

Please open a new issue; and a patch is welcome.

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

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

From report at bugs.python.org  Wed Sep  2 04:57:47 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 02 Sep 2009 02:57:47 +0000
Subject: [issue6817] char buffer in function posix_getcwdu should not be fix
	length
In-Reply-To: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>
Message-ID: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>


New submission from Boya Sun <boya.sun at case.edu>:

This issue is similar to issue 2722 (http://bugs.python.org/issue2722#), 
where the char buffer support that the path string has
not fixed length in the function posix_getcwd(). 

In the function posix_getcwdu(), the char buffer is still fix length. But 
I think the same change should also apply to this function.  A patch is 
attached to allow the char buffer in posix_getcwdu() to be not fixed 
length.

----------
files: patch_get_cwdu.diff
keywords: patch
messages: 92151
nosy: boya
severity: normal
status: open
title: char buffer in function posix_getcwdu should not be fix length
Added file: http://bugs.python.org/file14818/patch_get_cwdu.diff

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

From report at bugs.python.org  Wed Sep  2 04:59:48 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 02 Sep 2009 02:59:48 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1251860388.86.0.00517285545057.issue2722@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Amaury,

Created issue 6817 with a patch.

----------

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

From report at bugs.python.org  Wed Sep  2 05:17:08 2009
From: report at bugs.python.org (Mark Miller)
Date: Wed, 02 Sep 2009 03:17:08 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251861428.47.0.782899378121.issue6802@psf.upfronthosting.co.za>


Mark Miller <mark at mirell.org> added the comment:

This patch allows compiling, and forces everything to be x86_64. 
However, Python 2.6.2 still dies when attempting to install: 

cd Mac && make installmacsubtree DESTDIR=""
DYLD_FRAMEWORK_PATH=/tmp/Python-2.6.2:  ../python.exe 
./scripts/cachersrc.py -v 
/tmp/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth
on2.6/plat-mac 
/tmp/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tool
s
Traceback (most recent call last):
  File "./scripts/cachersrc.py", line 44, in <module>
    main()
  File "./scripts/cachersrc.py", line 41, in main
    os.path.walk(dir, handler, (verbose, force))
  File "../Lib/posixpath.py", line 224, in walk
    func(arg, top, names)
  File "./scripts/cachersrc.py", line 23, in handler
    macresource.open_pathname(os.path.join(dirname, fn), 
verbose=verbose)
  File "/private/tmp/Python-2.6.2/Lib/plat-mac/macresource.py", line 81, 
in open_pathname
    refno = Res.FSpOpenResFile(pathname, 1)
AttributeError: 'module' object has no attribute 'FSpOpenResFile'
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2

This is both with MacPorts, and without MacPorts, in the path, just for 
those who were wary that this was solely a MacPorts issue. 

The reason it is dying is because a large number of the calls in Carbon 
are completely non-existant in 64-bit userspace. An example would be FSpOpenResFile as seen above. 

Apple issued a notice stating that many of these calls would not exist 
in Carbon 64-bit 
(http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/
Carbon64BitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40
004381-CH1-SW1). 

What Apple apparently did for their shipped version of Python in Snow 
Leopard was a hack to combine 32-bit parts of Python for Carbon 32-bit 
support, and 64-bits. 
(http://www.opensource.apple.com/source/python/python-44/)

The only way I see currently to compile Python 2.6.2 natively on Mac OS 
10.6 (On a *64-Bit Capable* machine, this is critical) is to add the 
EXTRA_CFLAG "-m32" and patch Makefile.in, for two sections which 
completely ignore/don't include EXTRA_CFLAGS or PY_CFLAGS, or any 
CFLAGS. This pretty much limits you to a 32-bit version of Python. 
Because even doing "--host=i686-apple-darwin10 --target=i686-apple-
darwin10 --with-universal-archs=32-bit", since the default gcc target on 
a 64-bit capable machine is x86_64, it still produces x86_64 code in 
some areas.

By doing this, I was able to get Python 2.6.2 to compile *and* install. 
I'll submit a patch shortly, but the main issue is of course that 
plat_mac contains many 32-bit only references to the Carbon API. The 
true fix is to fix that area. But in the interim, you'll have to compile 
Python as 32-bit.

Also, the configure.in patch won't suffice for now, since you *can't* 
build a 64-bit version of Python on MacOSX from what I've seen, and also 
as reported by several other users on MacPorts.

----------
nosy: +mirell

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

From report at bugs.python.org  Wed Sep  2 06:42:13 2009
From: report at bugs.python.org (Ross)
Date: Wed, 02 Sep 2009 04:42:13 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>


New submission from Ross <rossmclendon at tamu.edu>:

It would be most helpful if a method could be included in the TarFile
class of the tarfile module and the ZipFile class of the zipfile module
that would remove a particular file (either given by a name or a
TarInfo/ZipInfo object) from the archive.

Usage to remove a single file from an archive would be as follows:

import zipfile
zipFileObject = zipfile.ZipFile(archiveName,'a')
zipFileObject.remove(fileToRemove)
zipFileObject.close()

Such a method should probably only apply to archives that are in append
mode as write mode would erase the original archive and read mode should
render the archive immutable.

One possible extra to be included is to allow a list of file names or
ZipInfo/TarInfo objects to be passed into the remove method, such that
all items in the list would be removed from the archive.

----------
components: Library (Lib)
messages: 92154
nosy: rossmclendon
severity: normal
status: open
title: remove/delete method for zipfile/tarfile objects
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Sep  2 06:43:08 2009
From: report at bugs.python.org (Ross)
Date: Wed, 02 Sep 2009 04:43:08 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251866588.6.0.921071468135.issue6818@psf.upfronthosting.co.za>


Changes by Ross <rossmclendon at tamu.edu>:


----------
components: +IO

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

From report at bugs.python.org  Wed Sep  2 07:20:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Sep 2009 05:20:41 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251868841.25.0.767997779956.issue6818@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/issue6818>
_______________________________________

From report at bugs.python.org  Wed Sep  2 07:42:59 2009
From: report at bugs.python.org (Ross)
Date: Wed, 02 Sep 2009 05:42:59 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251870179.5.0.203654130134.issue6818@psf.upfronthosting.co.za>


Ross <rossmclendon at tamu.edu> added the comment:

Slight change to:

"Such a method should probably only apply to archives that are in append
mode as write mode would erase the original archive and read mode should
render the archive immutable."

The method should probably still apply to an archive in write mode.  It
is conceivable that one may need to delete a file from the archive after
it has been written but before the archive object has been closed.

----------

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

From report at bugs.python.org  Wed Sep  2 08:01:58 2009
From: report at bugs.python.org (Jon Parise)
Date: Wed, 02 Sep 2009 06:01:58 +0000
Subject: [issue6819] Typo in datamodel.rst ("Custon" -> "Custom")
In-Reply-To: <1251871318.67.0.564956754608.issue6819@psf.upfronthosting.co.za>
Message-ID: <1251871318.67.0.564956754608.issue6819@psf.upfronthosting.co.za>


New submission from Jon Parise <jon at indelible.org>:

reference/datamodel.rst misspells "Custom" as "Custon".  The attached
patch fixes that.

----------
assignee: georg.brandl
components: Documentation
files: datamodel.custon.diff
keywords: patch
messages: 92157
nosy: georg.brandl, jon
severity: normal
status: open
title: Typo in datamodel.rst ("Custon" -> "Custom")
versions: Python 3.2
Added file: http://bugs.python.org/file14819/datamodel.custon.diff

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

From report at bugs.python.org  Wed Sep  2 09:00:19 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Sep 2009 07:00:19 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251874819.23.0.453285346815.issue6818@psf.upfronthosting.co.za>


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

-1. I don't think this can be implemented in a reasonable way, assuming
that you want the file to become smaller as a consequence of removal.

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

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

From report at bugs.python.org  Wed Sep  2 11:39:46 2009
From: report at bugs.python.org (rgpitts)
Date: Wed, 02 Sep 2009 09:39:46 +0000
Subject: [issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors.
In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
Message-ID: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>


New submission from rgpitts <richard.pitts at cdl.co.uk>:

I'm working with the Python C API and omniOrb with Visual Studio 2008 
on Windows XP. 

A OmniOrb header corba_sys_dep.h is defining HAVE_STRFTIME as 1
...
#define HAVE_STRFTIME 1
...

pyconfig.h is then defining this again. 
...
#define HAVE_STRFTIME
...

This is raising a compiler warning and then multiple syntax errors in 
math.h depending on the order of inclusion of these headers. If the 
pyconfig.h is included after corba_sys_dep.h multiple syntax errors. 
However if it is included before only a warning is raised.

I think pyconfig.h needs changing to
#ifndef HAVE_STRFTIME
#define HAVE_STRFTIME
#endif

----------
components: Windows
messages: 92159
nosy: rgpitts
severity: normal
status: open
title: Redefinition of HAVE_STRFTIME can cause compiler errors.
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed Sep  2 11:56:19 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Wed, 02 Sep 2009 09:56:19 +0000
Subject: [issue4160] library.pdf - Section 12.13.2 Connection Objects -
	example cut off at the right hand side
In-Reply-To: <1224601594.18.0.145893129918.issue4160@psf.upfronthosting.co.za>
Message-ID: <1251885379.0.0.66234174347.issue4160@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmail.com> added the comment:

I checked the 2.6.2 version of the PDF, dated 2nd September 2009, and
the problem is gone. The call can be closed.

----------

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

From report at bugs.python.org  Wed Sep  2 12:03:17 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Wed, 02 Sep 2009 10:03:17 +0000
Subject: [issue4159] Table about Standard Encodings is cut off at the bottom -
	35 entries missing
In-Reply-To: <1224600485.7.0.778638686943.issue4159@psf.upfronthosting.co.za>
Message-ID: <1251885797.8.0.357386638401.issue4159@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmail.com> added the comment:

I checked the current 2.6.2 documentation today (2nd September 2009):
the tables are not cut off at the bottom any more, but the layout is
still not optimal. The column width could be calculated more
efficiently. The column named "Aliases" is too wide and forces the
column "Languages" too far to the right.

----------

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

From report at bugs.python.org  Wed Sep  2 12:06:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Sep 2009 10:06:50 +0000
Subject: [issue4160] library.pdf - Section 12.13.2 Connection Objects -
	example cut off at the right hand side
In-Reply-To: <1224601594.18.0.145893129918.issue4160@psf.upfronthosting.co.za>
Message-ID: <1251886010.69.0.152922719217.issue4160@psf.upfronthosting.co.za>


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

This problem is somewhat similar to #5388, but if what you reported is
now fixed I'll close this issue.

----------
nosy: +ezio.melotti
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Sep  2 13:02:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Sep 2009 11:02:14 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1251889334.07.0.969471545282.issue6715@psf.upfronthosting.co.za>


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

Are xz and lzma formats compatible with each other? If not, which one is
the most popular?

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

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

From report at bugs.python.org  Wed Sep  2 14:11:14 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 02 Sep 2009 12:11:14 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251893474.33.0.828162470395.issue6818@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

-1, although I can only speak for tarfile. Removing members from a tar
archive sounds obvious and easy but it is *not*. A file in an archive is
stored as a header block (that contains the metadata) followed by a
number of data blocks (that contain the file's data). New files are
simply appended to the archive file. There is no central table of
contents whatsoever. To make things worse, a compressed archive is
compressed in one go from the beginning right up to the end, it is not
possible to access a member in the middle of an archive without having
to decompress all data before it.
Deleting files from an uncompressed archive is rather straightforward
implementation-wise but IO intensive and risky. In contrast, there is no
other way to delete files from a *compressed* tarfile than to make a
copy of it omitting the unwanted files.

----------
nosy: +lars.gustaebel

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

From report at bugs.python.org  Wed Sep  2 14:40:25 2009
From: report at bugs.python.org (egreen)
Date: Wed, 02 Sep 2009 12:40:25 +0000
Subject: [issue6821] incorrect doc for PyBuffer_Release
In-Reply-To: <1251895225.69.0.615338727818.issue6821@psf.upfronthosting.co.za>
Message-ID: <1251895225.69.0.615338727818.issue6821@psf.upfronthosting.co.za>


New submission from egreen <egreen at operamail.com>:

In documentation (c-api/buffer.html):

  void PyBuffer_Release(PyObject *obj, Py_buffer *view)

should be:

  void PyBuffer_Release(Py_buffer *view)

(as per Include/abstract.h)

----------
assignee: georg.brandl
components: Documentation
messages: 92165
nosy: egreen, georg.brandl
severity: normal
status: open
title: incorrect doc for PyBuffer_Release
versions: Python 3.1

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

From report at bugs.python.org  Wed Sep  2 15:01:29 2009
From: report at bugs.python.org (Robert DeVaughn)
Date: Wed, 02 Sep 2009 13:01:29 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>


New submission from Robert DeVaughn <rdevaughn at gmail.com>:

When attempting to store a file via FTP, the following error occurs. See 
attached code.

Traceback (most recent call last):
  File "C:\Documents and 
Settings\rdevaughn\Desktop\HTTP\src\FTP_directory.py", line 14, in 
<module>
    ftp.storlines("STOR source.txt",f)
  File "C:\Python30\lib\ftplib.py", line 477, in storlines
    if buf[-1] in B_CRLF: buf = buf[:-1]
TypeError: Type str doesn't support the buffer AP

----------
components: Library (Lib)
files: module.txt
messages: 92166
nosy: rdevaughn
severity: normal
status: open
title: Error calling .storlines from ftplib
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file14820/module.txt

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

From report at bugs.python.org  Wed Sep  2 16:22:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Sep 2009 14:22:52 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1251901372.99.0.55115312404.issue6715@psf.upfronthosting.co.za>


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

As I understand it from the http://tukaani.org/xz/ page, .lzma and .xz
are two file formats bases on the lzma compression method.
- .lzma simply stores the compressed stream.
- .xz is more complex

----------

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

From report at bugs.python.org  Wed Sep  2 16:24:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Sep 2009 14:24:09 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1251901449.33.0.632121243826.issue6822@psf.upfronthosting.co.za>


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


----------
type: compile error -> behavior

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

From report at bugs.python.org  Wed Sep  2 17:01:26 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 02 Sep 2009 15:01:26 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1251903686.64.0.849841495659.issue3139@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

I am still a little bit confused.  Can you explain a little more in
detail? What is the difference between the suspicious code and the ones
that are fixed?

----------

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

From report at bugs.python.org  Wed Sep  2 17:30:05 2009
From: report at bugs.python.org (Keith Campbell)
Date: Wed, 02 Sep 2009 15:30:05 +0000
Subject: [issue6796] invalid print in tkinter\test\test_ttk\test_widgets.py
In-Reply-To: <1251853121.6.0.894518619594.issue6796@psf.upfronthosting.co.za>
Message-ID: <69CC32C3AD4CA84BBABA634B3EE3E5890341AB3EC2@IMCMBX2.MITRE.ORG>


Keith Campbell <keithc at mitre.org> added the comment:

You are correct. Thanks.
Keith

----------

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

From report at bugs.python.org  Wed Sep  2 17:40:51 2009
From: report at bugs.python.org (Richard Shapiro)
Date: Wed, 02 Sep 2009 15:40:51 +0000
Subject: [issue6823] time.strftime does unnecessary range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>


New submission from Richard Shapiro <rashapiro83 at gmail.com>:

in Modules/timemodule.c, in the routine time_strftime, there is a range
check on the tm_isdst field:

        if (buf.tm_isdst < -1 || buf.tm_isdst > 1) {
            PyErr_SetString(PyExc_ValueError,
                            "daylight savings flag out of range");
            return NULL;
        }

This check is incorrect, as the tm_isdst field is interpreted as less
than 0, 0, or greater than zero (see the comment at the top of the
routine, and the documentation for the strftime function).
Unfortunately, there exists at least one platform for which tm_isdst is
set to something other than -1, 0, or 1 (on IBM zOS it's apparently set
to 2 for daylight savings). This means that you can't do the obvious 
strftime(...,localtime(...)) to format a time.

The fix is to either remove the range check entirely, or else to
normalize the +1, -1, or 0. The former is preferred unless there is some
platform on which strftime doesn't do the right thing with values
outside the range of [-1,1]. 

This bug exists in 2.5.1 and 2.6.2. I haven't checked other versions.

----------
components: Library (Lib)
messages: 92170
nosy: rshapiro
severity: normal
status: open
title: time.strftime does unnecessary range check
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Sep  2 17:48:28 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Sep 2009 15:48:28 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1251906508.72.0.365811214903.issue1578269@psf.upfronthosting.co.za>


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

I plan to look at this, and if it looks okay, commit it. Let me know if
anyone has any remaining issues.

----------
nosy: +eric.smith
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Wed Sep  2 18:07:59 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Sep 2009 16:07:59 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1251907679.16.0.464350096916.issue1578269@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/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Sep  2 18:40:06 2009
From: report at bugs.python.org (Ross)
Date: Wed, 02 Sep 2009 16:40:06 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251909606.33.0.487001941515.issue6818@psf.upfronthosting.co.za>


Ross <rossmclendon at tamu.edu> added the comment:

In light of Lars's comment on the matter, perhaps this functionality
could be added to zip files only.  Surely it can be done, considering
that numerous utilities and even Windows Explorer provide such
functionality.  I must confess that I am unfamiliar with the inner
workings of file archives and compression, but seeing as it is
implemented in a number of places already, it seems logical that it
could be implemented in ZipFile as well.  I'll spend some time the next
few days educating myself about zip files and how this might be
accomplished.

----------

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

From report at bugs.python.org  Wed Sep  2 18:43:01 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Wed, 02 Sep 2009 16:43:01 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>


New submission from Ritesh Raj Sarraf <rrs at researchut.com>:

Whey I do a help (python-module), I get the help text as follows:

Help on module tempfile:

NAME
    tempfile - Temporary files.

FILE
    /usr/lib/python2.5/tempfile.py

MODULE DOCS
    http://www.python.org/doc/2.5.4/lib/module-tempfile.html

DESCRIPTION
    This module provides generic, low- and high-level interfaces for
    creating temporary files and directories.  The interfaces listed
    as "safe" just below can be used without fear of race conditions.
    Those listed as "unsafe" cannot, and are provided for backward
    compatibility only.

The link to the webpage lists the supported platforms for the module.
It would be good to have an entry stating the list of platforms supported
by the module, in the module doc itself.

----------
assignee: georg.brandl
components: Documentation
messages: 92173
nosy: georg.brandl, rickysarraf
severity: normal
status: open
title: help for a module should list supported platforms
versions: Python 2.5

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

From report at bugs.python.org  Wed Sep  2 18:43:43 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Wed, 02 Sep 2009 16:43:43 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1251909823.49.0.231559466954.issue6824@psf.upfronthosting.co.za>


Changes by Ritesh Raj Sarraf <rrs at researchut.com>:


----------
type:  -> feature request

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

From report at bugs.python.org  Wed Sep  2 20:10:41 2009
From: report at bugs.python.org (devurandom)
Date: Wed, 02 Sep 2009 18:10:41 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1251915041.55.0.817288102538.issue6715@psf.upfronthosting.co.za>


devurandom <devurandom at gmx.net> added the comment:

.lzma is actually not a format. It is just the raw output of the LZMA1
coder. XZ instead is a container format for the LZMA2 coder, which
probably means LZMA+some metadata.
XZ is the official successor to .lzma, and GNU is using it already
(look at coreutils), and GNU tar officially supports it since 1.22.

----------

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

From report at bugs.python.org  Wed Sep  2 20:45:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Sep 2009 18:45:12 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1251903686.64.0.849841495659.issue3139@psf.upfronthosting.co.za>
Message-ID: <4A9EBD34.6010305@v.loewis.de>


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

A problem can only occur if you preserve a pointer to the buffer,
and the object gets a chance to change its buffer underneath. This
can happen when there are user-defined callback, and when other
threads can get control. In the cases being fixed, other threads
*can* get control, as the GIL is released. In the cases you discuss,
this cannot happen, since the GIL is not released, and no codepath
can lead to buffer reallocation.

----------

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

From report at bugs.python.org  Wed Sep  2 20:50:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Sep 2009 18:50:40 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <1251906508.72.0.365811214903.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4A9EBE7D.2000008@v.loewis.de>


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

> I plan to look at this, and if it looks okay, commit it. Let me know if
> anyone has any remaining issues.

I have the general issue that the semantics of the Windows symlink
implementation are ill-defined. Specifically for the patch, I think
precise documentation of the implemented behavior is is missing (unless
it behaves like Unix symlink to the tiniest detail, which I doubt).
Without an exact specification of what it should do it is difficult
to tell whether it does that correctly.

----------
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  Wed Sep  2 20:54:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Sep 2009 18:54:27 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251909606.33.0.487001941515.issue6818@psf.upfronthosting.co.za>
Message-ID: <4A9EBF60.3070003@v.loewis.de>


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

> In light of Lars's comment on the matter, perhaps this functionality
> could be added to zip files only.  Surely it can be done, considering
> that numerous utilities and even Windows Explorer provide such
> functionality.

Are you sure they are not creating a new file in order to delete
content? I recall that early zip tools (e.g. pkzip) had a mode
where they would merely delete the entry from the directory, but
leave the actual data in the file. Would you consider that a correct
implementation? If so, *that* can be done, for zipfiles, AFAIU.

> I'll spend some time the next
> few days educating myself about zip files and how this might be
> accomplished.

Please do - you'll find that deletion from zipfiles comes in a can
full of worms.

----------

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

From report at bugs.python.org  Wed Sep  2 22:18:37 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 02 Sep 2009 20:18:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1251922717.12.0.883117380874.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The deviance between the Unix and Windows symlink functions is apparent
in the signature, though not explicitly-defined in any formal
documentation.  Perhaps the following could be included as formal
documentation.  Should this documentation be added to os.rst, or would
another place be better?

The Windows version takes an additional, optional parameter,
target_is_directory, which defaults to False.

On Windows, a symlink represents a file or a directory, and does not
morph to the target dynamically.  For this reason, when creating a
symlink on Windows, if the target is not already present, the symlink
will default to being a file symlink.  If target_is_directory is set to
True, the symlink will be created as a directory symlink.  This
parameter is ignored if the target exists (and the symlink is created
with the same type as the target).

----------

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

From report at bugs.python.org  Wed Sep  2 22:31:57 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Sep 2009 20:31:57 +0000
Subject: [issue6819] Typo in datamodel.rst ("Custon" -> "Custom")
In-Reply-To: <1251871318.67.0.564956754608.issue6819@psf.upfronthosting.co.za>
Message-ID: <1251923517.33.0.751426602283.issue6819@psf.upfronthosting.co.za>


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

Thanks, fixed in r74627.

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

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

From report at bugs.python.org  Wed Sep  2 22:35:24 2009
From: report at bugs.python.org (Evan Driscoll)
Date: Wed, 02 Sep 2009 20:35:24 +0000
Subject: [issue6825] Minor documentation bug with os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>


New submission from Evan Driscoll <evaned at gmail.com>:

The documentation for os.path.split says, in part:

  "In nearly all cases, join(head, tail) equals path (the only 
  exception being when there were multiple slashes separating head
  from tail)."

But this is not quite true: that's not the *only* exception, at least
without a somewhat liberal definition of "equals".

This can also happen if os.altsep is used in the path being split, in
which case it will be replaced by os.sep:

>>> import ntpath
>>> path = "a/b"
>>> (head, tail) = ntpath.split(path)
>>> joined = ntpath.join(head, tail)
>>> joined == path
False
>>> joined
'a\\b'


[I only selected the versions that I actually verified, but I would
guess it's present in more.]

----------
assignee: georg.brandl
components: Documentation
messages: 92180
nosy: evaned, georg.brandl
severity: normal
status: open
title: Minor documentation bug with os.path.split
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Sep  2 22:37:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Sep 2009 20:37:41 +0000
Subject: [issue6821] incorrect doc for PyBuffer_Release
In-Reply-To: <1251895225.69.0.615338727818.issue6821@psf.upfronthosting.co.za>
Message-ID: <1251923861.16.0.546990053383.issue6821@psf.upfronthosting.co.za>


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

Thanks, fixed in r74631, will be merged to other branches soon.

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

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

From report at bugs.python.org  Wed Sep  2 22:38:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Sep 2009 20:38:40 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <1251922717.12.0.883117380874.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4A9ED7CD.1070805@v.loewis.de>


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

> Should this documentation be added to os.rst, or would
> another place be better?

Definitely the current documentation of these APIs, yes.
The parameter should appear in the signature also, with then
the remark that it works Windows only.

There should also be a versionchanged markup.

I think there are also effects on stat/lstat, IIRC; if so,
they should be documented as well. If there are now differences,
ISTM that you can't find out whether a link is a directory symlink;
if so, *that* should be documented.

----------

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

From report at bugs.python.org  Wed Sep  2 22:42:21 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Sep 2009 20:42:21 +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: <1251924141.07.0.562738425521.issue5705@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Wed Sep  2 22:42:30 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Sep 2009 20:42:30 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1251924150.86.0.763344556009.issue2620@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Wed Sep  2 22:49:20 2009
From: report at bugs.python.org (Joseph Thomson)
Date: Wed, 02 Sep 2009 20:49:20 +0000
Subject: [issue6826] Add __contains__ to range type
In-Reply-To: <1251924560.8.0.143337742055.issue6826@psf.upfronthosting.co.za>
Message-ID: <1251924560.8.0.143337742055.issue6826@psf.upfronthosting.co.za>


New submission from Joseph Thomson <joseph.thomson at gmail.com>:

The range type should implement the __contains__ method.  Currently an
expression like 'x in range(10000000)' will iterate through every item
in the range (exiting when an item tests true for equality); this is
highly unnecessary as the following expression will perform the same
function in a fraction of the time:

value >= start and value < stop and (value - start) % step == 0

The biggest advantage of this modification would be to allow users to say:

if foo in range(lower, upper):
   bar()

instead of:

if foo >= lower and foo < upper:
   bar()

safe in the knowledge that they are losing no performance.  The former
is also far more Pythonic in my opinion :).

If there is still any doubt (which I doubt), I have attached an example
script showing what is to be gained.

----------
components: Interpreter Core
files: range.py
messages: 92183
nosy: hpesoj
severity: normal
status: open
title: Add __contains__ to range type
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file14821/range.py

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

From report at bugs.python.org  Wed Sep  2 22:55:27 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 02 Sep 2009 20:55:27 +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: <1251924927.37.0.798564520976.issue5705@psf.upfronthosting.co.za>


Changes by Joe Amenta <amentajo at msu.edu>:


----------
nosy: +joe.amenta

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

From report at bugs.python.org  Wed Sep  2 23:09:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Sep 2009 21:09:59 +0000
Subject: [issue6826] Add __contains__ to range type
In-Reply-To: <1251924560.8.0.143337742055.issue6826@psf.upfronthosting.co.za>
Message-ID: <1251925799.45.0.265253121322.issue6826@psf.upfronthosting.co.za>


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

Closing this as a duplicate of issue 1766304.  Joseph, please could you 
renew the discussion in that issue instead?

----------
nosy: +marketdickinson
resolution:  -> duplicate
status: open -> closed
superseder:  -> improve xrange.__contains__

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

From report at bugs.python.org  Wed Sep  2 23:10:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Sep 2009 21:10:46 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251925846.59.0.630047860613.issue1766304@psf.upfronthosting.co.za>


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

Closed issue 6826 as a duplicate of this issue.

----------
nosy: +marketdickinson

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

From report at bugs.python.org  Wed Sep  2 23:12:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Sep 2009 21:12:12 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251925932.63.0.0161315106982.issue1766304@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Sep  2 23:18:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Sep 2009 21:18:42 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251926322.86.0.229611894414.issue1766304@psf.upfronthosting.co.za>


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


----------
nosy: +hpesoj

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

From report at bugs.python.org  Wed Sep  2 23:29:52 2009
From: report at bugs.python.org (Shaun Cutts)
Date: Wed, 02 Sep 2009 21:29:52 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
	__getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>


New submission from Shaun Cutts <shauncutts at users.sourceforge.net>:

Line 335 of copy.py guards call to __setstate__ with

if state:
    ...

However, __getstate__ may legitimately return an empty dictionary even
if __setstate__ still needs to be called. For example,
__setstate__/__getstate__ pair may not want to "persist" default values
(as is the case for me).

The fix would be to change this line to (e.g.):

if state is not None:
    ...

----------
components: Library (Lib)
files: deepcopy_bug.py
messages: 92186
nosy: shauncutts
severity: normal
status: open
title: deepcopy erroneously doesn't call __setstate__ if __getstate__ returns empty dict
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14822/deepcopy_bug.py

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

From report at bugs.python.org  Wed Sep  2 23:46:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Sep 2009 21:46:12 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251927972.82.0.0111203605598.issue1766304@psf.upfronthosting.co.za>


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

+1 for an O(1) contains-test.

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

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

From report at bugs.python.org  Wed Sep  2 23:47:13 2009
From: report at bugs.python.org (Joseph Thomson)
Date: Wed, 02 Sep 2009 21:47:13 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251928033.27.0.432724191711.issue1766304@psf.upfronthosting.co.za>


Joseph Thomson <joseph.thomson at gmail.com> added the comment:

Seeing as the range type has most likely stabalised by now, I would like
to renew this issue.  The current behaviour of range/xrange could
introduce unforeseen performance issues if users are not aware of its
inner workings.

Also, as I said in my closed duplicate issue, 'if value in range(lower,
upper)' to me looks far more Pythonic than 'if value >= lower and value
< upper'.  Although this may be a minor point, I think it is noteworthy.

As for the prospect of producing a patch myself, I have checked out and
taken a look at the code, but it is somewhat alien to me, and I thought
it'd probably be more sensible to leave it to the people who know what
they're doing.

----------

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

From report at bugs.python.org  Wed Sep  2 23:57:56 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Sep 2009 21:57:56 +0000
Subject: [issue6579] No update about automatic numbering of fields in format
	strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1251928676.72.0.519764708392.issue6579@psf.upfronthosting.co.za>


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

This is a duplicate of issue 6813, where it has been fixed. I'm closing it.

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

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

From report at bugs.python.org  Thu Sep  3 04:44:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 03 Sep 2009 02:44:42 +0000
Subject: [issue6828] wrongly highlighted blocks in the Tutorial
In-Reply-To: <1251945881.72.0.464228919269.issue6828@psf.upfronthosting.co.za>
Message-ID: <1251945881.72.0.464228919269.issue6828@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

In the tutorial, some blocks were wrongly highlighted as being Python 
code when they were actually just program output.

This patch adds the missing ``highlightlang:: none`` declarations.

See http://permalink.gmane.org/gmane.comp.python.general/636597

----------
assignee: georg.brandl
components: Documentation
files: introduction.diff
keywords: patch
messages: 92190
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: wrongly highlighted blocks in the Tutorial
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14823/introduction.diff

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

From report at bugs.python.org  Thu Sep  3 09:20:20 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Sep 2009 07:20:20 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It is an error to try to inherit from function and the error message in 
this case is:
{{{
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "m:\p\pb.py", line 4, in <module>
    class PostgreSQLConnection(DatabaseConnection):
TypeError: Error when calling the metaclass bases
    function() argument 1 must be code, not str
}}}

Something like 'Impossible to inherit from function' will clear 
confusion state from users unfamiliar with metaclasses.
{{{
def DatabaseConnection(object):
    pass

class PostgreSQLConnection(DatabaseConnection):
    pass
}}}

----------
components: Interpreter Core
messages: 92191
nosy: techtonik
severity: normal
status: open
title: Frendly error message when inheriting from function
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Sep  3 09:27:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Sep 2009 07:27:38 +0000
Subject: [issue6828] wrongly highlighted blocks in the Tutorial
In-Reply-To: <1251945881.72.0.464228919269.issue6828@psf.upfronthosting.co.za>
Message-ID: <1251962858.83.0.542905179216.issue6828@psf.upfronthosting.co.za>


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

Thanks, fixed in r74632.

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

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

From report at bugs.python.org  Thu Sep  3 10:23:50 2009
From: report at bugs.python.org (Toshihiro Kamiya)
Date: Thu, 03 Sep 2009 08:23:50 +0000
Subject: [issue6830] Some uniformness in defaultdict
In-Reply-To: <1251966230.42.0.696554317136.issue6830@psf.upfronthosting.co.za>
Message-ID: <1251966230.42.0.696554317136.issue6830@psf.upfronthosting.co.za>


New submission from Toshihiro Kamiya <t-kamiya at aist.go.jp>:

I found the syntax of collections.defaultdict is confusing, at least to 
me.

When I need a defaultdict of int, that is, a defaultdict which contains 
int objects, I can write simply:
a = defaultdict(int)

However, when I want a defaultdict of defaultdict of something, I can't 
write:
d = defaultdict(defaultdict(int))

This raises TypeError.

I understand the argument of defaultdict is not a type (or class), but 
a factory by definition. So I should to write:
d = defaultdict(lambda: defaultdict(int))

But this syntax is somehow confusing to me.
Am I missing some important feature of defaultdict?

The workaround that I've found is:

import collections
class __Helper(object):
  def __getitem__(self, ctor):
    return lambda: collections.defaultdict(lambda: ctor())
genericdefaultdict = __Helper()

This helper introduce some generics flavor in defaultdict.
The above cases can be spelt out:

a = genericdefaultdict[int]()
d = genericdefaultdict[genericdefaultdict[int]]()

----------
components: Library (Lib)
files: ddh.py
messages: 92193
nosy: t-kamiya
severity: normal
status: open
title: Some uniformness in defaultdict
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file14824/ddh.py

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

From report at bugs.python.org  Thu Sep  3 10:24:13 2009
From: report at bugs.python.org (=?utf-8?q?Jonas_Bystr=C3=B6m?=)
Date: Thu, 03 Sep 2009 08:24:13 +0000
Subject: [issue6831] 2to3 assignment division conversion
In-Reply-To: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>
Message-ID: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>


New submission from Jonas Bystr?m <highfestiva at gmail.com>:

Code from 2.x containing __idiv__ does not translate into

def __floordiv__(self, x): self.__truediv__(x)
def __truediv__(self, x): ...

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 92194
nosy: highfestiva
severity: normal
status: open
title: 2to3 assignment division conversion
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Sep  3 11:18:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Sep 2009 09:18:19 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251969499.52.0.834524253559.issue1766304@psf.upfronthosting.co.za>


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

The py3k patch no longer works:  it makes use of PyObject_Cmp, which no
longer exists.

----------

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

From report at bugs.python.org  Thu Sep  3 11:29:55 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 03 Sep 2009 09:29:55 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
Message-ID: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>


New submission from Jerzy <jerzyo at genesilico.pl>:

Hi

When I am outputting unicode strings to terminal my script works OK, but
when I redirect it to file I get a crash:

$ python mailing/message_sender.py -l Bia
Bia?ystok

$ python mailing/message_sender.py -l Bia > ~/tmp/aaa.txt 
Traceback (most recent call last):
  File "mailing/message_sender.py", line 71, in <module>
    list_groups(unicode(args[0],'utf-8'))
  File "mailing/message_sender.py", line 53, in list_groups
    print group[1].name
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in
position 3: ordinal not in range(128)

----------
components: Unicode
messages: 92196
nosy: Orlowski
severity: normal
status: open
title: Outputting unicode crushes when printing to file on Linux
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Sep  3 12:03:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Sep 2009 10:03:18 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251972198.65.0.0140565392518.issue1766304@psf.upfronthosting.co.za>


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

The trunk patch is also unacceptable in its current form:

 1. there are no docs or tests
 2. keyval, start, step and end should have type long, not type int
    (as Antoine already mentioned)
 3. the expression ((keyval - start) % step) can overflow, leading to
    undefined behaviour (e.g., wrong results, segfaults, strange
    effects from gcc optimizations that assume no overflow).  For
    example, with the patch, on Linux/x86-64, I get:

      >>> x = xrange(-2000000000, 2000000000, 5)
      >>> 1000000000 in x
      False

    This should be relatively easy to fix:  e.g., if you already
    know that step > 0 and start <= keyval and keyval < stop, then
    '(unsigned long)keyval - (unsigned long)start'  is safe from
    overflow.

 4. the containment check only works for ints:  with the patch, I get:

      >>> x = xrange(10)
      >>> 4 in x
      True
      >>> 4L in x
      False
      >>> 4.0 in x
      False

    but without the patch applied, all these return True.  It's possible
    that it's worth special-casing integer inputs for the sake of
    speed, but I don't think the behaviour should change like this for
    other types.

----------

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

From report at bugs.python.org  Thu Sep  3 12:06:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Sep 2009 10:06:56 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1251972416.91.0.634042209085.issue1766304@psf.upfronthosting.co.za>


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

[Joseph Thomson]
> Also, as I said in my closed duplicate issue, 'if value in range(lower,
> upper)' to me looks far more Pythonic than 'if value >= lower and value
> < upper'.

Note that the Pythonic spelling would be:  'if lower <= value < upper'.
 (Though that's not quite the same thing if value is not an integer.)

----------

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

From report at bugs.python.org  Thu Sep  3 13:25:32 2009
From: report at bugs.python.org (Paul van der Linden)
Date: Thu, 03 Sep 2009 11:25:32 +0000
Subject: [issue6833] incorrect: failed local variable referenced before
	assignment
In-Reply-To: <1251977132.94.0.194945951914.issue6833@psf.upfronthosting.co.za>
Message-ID: <1251977132.94.0.194945951914.issue6833@psf.upfronthosting.co.za>


New submission from Paul van der Linden <paul at soulbase.nl>:

The attached python file will give the following output, which is 
incorrect behavior as far as I know:
"
this will fail
failed local variable 'in_std' referenced before assignment

this won't fail
Not failed
this won't fail either
Not failed
"

This is tested on windows with python2.6(standard msi) and on centos 
5.3 with python2.6 (custom rpm), python2.4 (system rpm), freebsd with 
python2.5 (system package), python2.6 ("hand" compiled) and python3.0 
("hand" compiled).

The attached code is stripped down to the bare minimum and therefore 
won't do anything usefull.

----------
components: None
files: bug.py
messages: 92199
nosy: paultjuhatwork
severity: normal
status: open
title: incorrect: failed local variable referenced before assignment
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14825/bug.py

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

From report at bugs.python.org  Thu Sep  3 13:30:55 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Sep 2009 11:30:55 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
	__getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1251977455.73.0.00218596516986.issue6827@psf.upfronthosting.co.za>


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

This is precisely documented here:
http://docs.python.org/library/pickle.html#object.__setstate__
"Note: For new-style classes, if __getstate__() returns a false value,
the __setstate__() method will not be called."

If you want some default value even when the state is empty, you could
set it in the __new__ method:
[__new__ is always called, but __init__ is skipped by the copy protocol]

class A(object):
    def __new__(cls):
        self = super(cls, A).__new__(cls)
        self.a = 1
        return self
    def __setstate__(self, d):
        self.__dict__.update(d)
    def __getstate__(self):
        d = self.__dict__.copy()
        d.pop('a')
        return d

The __setstate__ is even not necessary here, since it implements the
default behaviour.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> pending

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

From report at bugs.python.org  Thu Sep  3 13:44:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Sep 2009 11:44:38 +0000
Subject: [issue6833] incorrect: failed local variable referenced before
	assignment
In-Reply-To: <1251977132.94.0.194945951914.issue6833@psf.upfronthosting.co.za>
Message-ID: <1251978278.05.0.706454716354.issue6833@psf.upfronthosting.co.za>


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

This is not a bug.  The behaviour you're seeing is described here:

http://docs.python.org/reference/executionmodel.html#naming-and-binding

"If a name binding operation occurs anywhere within a code block, all
uses of the name within the block are treated as references to the
current block. This can lead to errors when a name is used within a
block before it is bound. This rule is subtle. Python lacks declarations
and allows name binding operations to occur anywhere within a code
block. The local variables of a code block can be determined by scanning
the entire text of the block for name binding operations."

In the failing example, the registerdecorator function contains an
assignment to in_std, so by the rules above in_std is local to the
function.  The 'if in_std' line therefore tries to lookup 'in_std' in
the local namespace;  it doesn't exist (yet), so an UnboundLocalError
exception occurs.

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

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

From report at bugs.python.org  Thu Sep  3 13:51:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Sep 2009 11:51:04 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
Message-ID: <1251978664.39.0.0434825035937.issue6832@psf.upfronthosting.co.za>


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

You have to use an encoding that's not ascii then.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Thu Sep  3 14:01:33 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 03 Sep 2009 12:01:33 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251978664.39.0.0434825035937.issue6832@psf.upfronthosting.co.za>
Message-ID: <4A9FB006.7090602@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

I know how to make it work. The question is why outputting to file makes 
it crush when outputting to terminal does not.

I have never seen "$program > file" behaving in a different way than 
"$program" in any other language

Jerzy Orlowski

Benjamin Peterson wrote:
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> You have to use an encoding that's not ascii then.
>
> ----------
> nosy: +benjamin.peterson
> resolution:  -> works for me
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6832>
> _______________________________________
>
>
>
>

----------

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

From report at bugs.python.org  Thu Sep  3 14:19:36 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Sep 2009 12:19:36 +0000
Subject: [issue6830] Some uniformness in defaultdict
In-Reply-To: <1251966230.42.0.696554317136.issue6830@psf.upfronthosting.co.za>
Message-ID: <1251980376.36.0.912573965891.issue6830@psf.upfronthosting.co.za>


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

This won't change -- the argument of defaultdict is simply a callable
that is called with no arguments and returns the default value.

It works with `int` because `int()` can be called without arguments and
yields 0; however, `defaultdict` cannot.  Therefore, the lambda
expression you wrote is one of the correct ways to spell this.

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

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

From report at bugs.python.org  Thu Sep  3 14:22:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Sep 2009 12:22:09 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
Message-ID: <1251980529.03.0.218206602557.issue6832@psf.upfronthosting.co.za>


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

When output goes to a terminal, Python can determine its encoding. For a
file, it cannot, therefore it refuses to guess.

Also, many programs behave differently when used with redirection;
namely, all those that use `isatty()` to determine if stdout is a terminal.

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

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

From report at bugs.python.org  Thu Sep  3 14:24:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Sep 2009 12:24:26 +0000
Subject: [issue6823] time.strftime does unnecessary range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1251980666.82.0.450197660139.issue6823@psf.upfronthosting.co.za>


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

Assigning to Brett who added this check in r35368.

----------
assignee:  -> brett.cannon
nosy: +brett.cannon, georg.brandl

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

From report at bugs.python.org  Thu Sep  3 14:27:20 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 03 Sep 2009 12:27:20 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251980529.03.0.218206602557.issue6832@psf.upfronthosting.co.za>
Message-ID: <4A9FB612.2000008@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

Well, I would suggest using the terminal encoding as default one when 
redirecting. In my opinion sys.stdin and sys.stdout should always have 
the terminal encoding

Alternatively you could make the function sys.setdefaultencoding() 
visible to change it in a reasonable way

Jerzy

Georg Brandl wrote:
> Georg Brandl <georg at python.org> added the comment:
>
> When output goes to a terminal, Python can determine its encoding. For a
> file, it cannot, therefore it refuses to guess.
>
> Also, many programs behave differently when used with redirection;
> namely, all those that use `isatty()` to determine if stdout is a terminal.
>
> ----------
> nosy: +georg.brandl
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6832>
> _______________________________________
>
>
>
>

----------

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

From report at bugs.python.org  Thu Sep  3 14:31:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Sep 2009 12:31:48 +0000
Subject: [issue6757] Marshal's documentation incomplete (Bools)
In-Reply-To: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
Message-ID: <1251981108.6.0.625875640359.issue6757@psf.upfronthosting.co.za>


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

Thanks, fixed in r74633.

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

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

From report at bugs.python.org  Thu Sep  3 15:07:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Sep 2009 13:07:24 +0000
Subject: [issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors.
In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
Message-ID: <1251983244.01.0.210366839015.issue6820@psf.upfronthosting.co.za>


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

Those HAVE_XXX symbols should be defined like autoconf does:
#define HAVE_STRFTIME 1
This is what happens on Unix platforms, and AFAIK this plays well with
other libraries which define the same symbols.

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

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

From report at bugs.python.org  Thu Sep  3 15:54:35 2009
From: report at bugs.python.org (fideli)
Date: Thu, 03 Sep 2009 13:54:35 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251986075.56.0.924582638189.issue6802@psf.upfronthosting.co.za>


Changes by fideli <faisal.moledina at gmail.com>:


----------
nosy: +fideli

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

From report at bugs.python.org  Thu Sep  3 16:24:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Sep 2009 14:24:45 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Note: this is mostly a reminder for myself to clean up the pythonw stub 
executable

The current implementation of pythonw on OSX uses exec to start an 
executable inside the framework, this is needed to be able to use GUI 
functionality from the command-line without resorting to undocumented 
and unsupported system APIs. To deal with selection between 32-bit and 
64-bit the framework contains a number of python executables.

Using "posix_spawnattr_setbinpref_np", "posix_spawnattr_setflags" and 
"posix_spawn" it is possible to do away with the additional executables, 
leaving a simpler situation. 

Nice to have features:
* python(1) on SnowLeopard has a system preference to select between 32-
bit and 64-bit:

   $ defaults read com.apple.versioner.python  
   {
    "Prefer-32-Bit" = 1;
   }

(The "versioner" appears to be a private Apple library/tool, 
reimplementing the functionality would be fairly trivial)

* It would be nice to have a command-line switch as well

* It would be nice if the stub executable could be reused by tools like 
virtualenv without recompilation

----------
assignee: ronaldoussoren
components: Macintosh
keywords: easy
messages: 92210
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: use different mechanism for pythonw on osx
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Sep  3 16:28:28 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Sep 2009 14:28:28 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251988108.52.0.349595862224.issue6802@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

My current plan is to fix this issue, and the issue of 64-bit universal 
builds on SL in the weekend. 

BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no 
maintained beyond critical security patches.

----------

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

From report at bugs.python.org  Thu Sep  3 16:53:57 2009
From: report at bugs.python.org (Goetz Pfeiffer)
Date: Thu, 03 Sep 2009 14:53:57 +0000
Subject: [issue6835] doctest problem with decorated function when decorator is
	defined in separate file
In-Reply-To: <1251989637.01.0.106852845631.issue6835@psf.upfronthosting.co.za>
Message-ID: <1251989637.01.0.106852845631.issue6835@psf.upfronthosting.co.za>


New submission from Goetz Pfeiffer <goetzpf at googlemail.com>:

As described in bug 1108, doctest skips tests on 
functions that have been decorated with a decorator that 
is defined in a separate file.

As described in bug 1108, the problem lies in 
file "doctest.py", there in class "DocTestFinder",
there in method "_from_module"

There at about line 857 the following code makes problems:

        elif inspect.isfunction(object):
            return module.__dict__ is object.func_globals

The "func_globals" property of the function is used to find out if
the function was defined in the current module. This is not true
for a decorated function where the decorator is defined in another
module. Maybe _from_module() should use inspect.getmodulename() or
the "__module__" property of the function instead. "__module__"
is set correctly when the decorator uses functools.wraps().

The func_globals property is read-only, so there is no chance fix this
at the decorator definition.

----------
components: Library (Lib)
files: mytest.sh
messages: 92212
nosy: goetzpf
severity: normal
status: open
title: doctest problem with decorated function when decorator is defined in separate file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14826/mytest.sh

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

From report at bugs.python.org  Thu Sep  3 20:27:18 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Sep 2009 18:27:18 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251988108.52.0.349595862224.issue6802@psf.upfronthosting.co.za>
Message-ID: <bbaeab100909031126i10ba0e8bw41d468b0a2e6dead@mail.gmail.com>


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

On Thu, Sep 3, 2009 at 07:28, Ronald Oussoren<report at bugs.python.org> wrote:
>
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> My current plan is to fix this issue, and the issue of 64-bit universal
> builds on SL in the weekend.
>
> BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no
> maintained beyond critical security patches.

That's correct.

----------

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

From report at bugs.python.org  Thu Sep  3 20:27:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Sep 2009 18:27:36 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
Message-ID: <1252002456.67.0.789835528765.issue6832@psf.upfronthosting.co.za>


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

Using the terminal encoding for sys.stdout does not work in the general
case, as a (background) process may not *have* a controlling terminal
(such as a CGI script, a cron job, or a Windows service). That Python
recognizes the terminal encoding is primarily a convenience feature for
the interactive mode.

Exposing sys.setdefaultencoding is not implementable in a reasonable way.

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

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

From report at bugs.python.org  Thu Sep  3 20:43:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Sep 2009 18:43:21 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1252003401.92.0.594995038208.issue6834@psf.upfronthosting.co.za>


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

Can you kindly report how architecture selection works? Is there a
separate binary which execs? Some other magic?

Asking primarily out of curiosity, but if it's a launcher, then
(sym)linking it into a virtualenv might be sufficient.

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

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

From report at bugs.python.org  Thu Sep  3 21:38:54 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 03 Sep 2009 19:38:54 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1252002456.67.0.789835528765.issue6832@psf.upfronthosting.co.za>
Message-ID: <4AA01B35.8080309@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

OK, I give up.

The problem is that one might test a program on terminal and think that 
everything is running OK and then spend a reasonable amount of time 
trying to find the problem later

Another approach: couldn't utf8 be set as default encoding for all 
inputs and outputs?

I know that some of my questions are caused by the fact that I do not 
understand how python works. But You have to bear in mind that most of 
the people don't. Such behaviour of Python (see also 
http://bugs.python.org/issue5092) is illogical in the "common sense" for 
standard poeple. If interpreter does something illogical for me, I am 
more eager to switch to another language.

Jerzy

Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Using the terminal encoding for sys.stdout does not work in the general
> case, as a (background) process may not *have* a controlling terminal
> (such as a CGI script, a cron job, or a Windows service). That Python
> recognizes the terminal encoding is primarily a convenience feature for
> the interactive mode.
>
> Exposing sys.setdefaultencoding is not implementable in a reasonable way.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6832>
> _______________________________________
>
>
>
>

----------

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

From report at bugs.python.org  Thu Sep  3 22:13:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Sep 2009 20:13:00 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
Message-ID: <1252008780.91.0.422465026666.issue6832@psf.upfronthosting.co.za>


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

If you want to switch to a different language, consider switching to
Python 3. There, all strings are Unicode strings, and files opened in
text mode always use the locale encoding.

----------

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

From report at bugs.python.org  Thu Sep  3 22:38:49 2009
From: report at bugs.python.org (Jack Diederich)
Date: Thu, 03 Sep 2009 20:38:49 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1252010329.61.0.228217616435.issue6582@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

applied in r74638
and I've added you to Misc/ACKS
Thanks again for the patch!

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

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

From report at bugs.python.org  Thu Sep  3 22:42:59 2009
From: report at bugs.python.org (Jack Diederich)
Date: Thu, 03 Sep 2009 20:42:59 +0000
Subject: [issue6748] test test_telnetlib failed
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1252010579.51.0.677948885836.issue6748@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I think this is fixed by r74638 but it never triggered on my box (Ubuntu
9.x) so I can't be sure.  What distro are you using?

----------
assignee:  -> jackdied
nosy: +jackdied

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

From report at bugs.python.org  Thu Sep  3 23:04:47 2009
From: report at bugs.python.org (Rodrigo Steinmuller Wanderley)
Date: Thu, 03 Sep 2009 21:04:47 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1252010329.61.0.228217616435.issue6582@psf.upfronthosting.co.za>
Message-ID: <20090903180438.3ac35630@blackbug>


Rodrigo Steinmuller Wanderley <rwanderley at rsw.digi.com.br> added the comment:

On Thu, 03 Sep 2009 20:38:49 +0000
Jack Diederich <report at bugs.python.org> wrote:

> 
> Jack Diederich <jackdied at gmail.com> added the comment:
> 
> applied in r74638
> and I've added you to Misc/ACKS
> Thanks again for the patch!

No problem,

Anything I can do to improve telnetlib further?

I'm currently with plenty of time available and would appreciate the
opportunity to learn more Python.

Rodrigo

> ----------
> resolution:  -> accepted
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6582>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Sep  3 23:16:59 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Sep 2009 21:16:59 +0000
Subject: [issue6806] test_platform fails under Snow Leopard
In-Reply-To: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
Message-ID: <1252012619.06.0.386194859416.issue6806@psf.upfronthosting.co.za>


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

Got a fix, about to start applying it.

----------

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

From report at bugs.python.org  Thu Sep  3 23:24:10 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Thu, 03 Sep 2009 21:24:10 +0000
Subject: [issue6748] test test_telnetlib failed
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1252013050.74.0.575125850588.issue6748@psf.upfronthosting.co.za>


Thomas Kowaliczek <linuxdonald at linuxdonald.de> added the comment:

Fedora 11 64 Bit

----------

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

From report at bugs.python.org  Thu Sep  3 23:32:14 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Sep 2009 21:32:14 +0000
Subject: [issue6806] test_platform fails under Snow Leopard
In-Reply-To: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
Message-ID: <1252013534.71.0.457891422098.issue6806@psf.upfronthosting.co.za>


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

2.7: 74640
3.2: 74641
3.1: 74642

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

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

From report at bugs.python.org  Thu Sep  3 23:37:25 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Sep 2009 21:37:25 +0000
Subject: [issue6823] time.strftime does unnecessary range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1252013845.13.0.227933500966.issue6823@psf.upfronthosting.co.za>


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

Ugh, damn platforms and having to be different. =)

Normalization is the best solution as Python's docs says the expected 
value for the tm_dst field is -1, 0, or 1 (which is why I added the 
check).

----------
keywords: +easy
priority:  -> low
stage:  -> test needed

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

From report at bugs.python.org  Fri Sep  4 00:25:54 2009
From: report at bugs.python.org (Tim Hatch)
Date: Thu, 03 Sep 2009 22:25:54 +0000
Subject: [issue2649] poss. patch for fnmatch.py to add {.htm,
	html} style globbing
In-Reply-To: <1208433404.5.0.648159158993.issue2649@psf.upfronthosting.co.za>
Message-ID: <1252016754.22.0.353482125848.issue2649@psf.upfronthosting.co.za>


Tim Hatch <tim at timhatch.com> added the comment:

More discussion has gone on in issue #4573 on this topic.  Can this bug
be marked as a duplicate?

----------
nosy: +thatch

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

From report at bugs.python.org  Fri Sep  4 01:11:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Sep 2009 23:11:20 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1252019480.67.0.422712232535.issue6824@psf.upfronthosting.co.za>


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

I'm not sure to understand. The web page says the module "works on all 
supported platforms." Many python features works equally well on all 
platforms, and I don't feel necessary to repeat this everywhere.
The differences between platforms are more interesting IMO.

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

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

From report at bugs.python.org  Fri Sep  4 04:37:34 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 04 Sep 2009 02:37:34 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1252031854.87.0.203503670663.issue5329@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

The subprocess docs (in Doc/library/subprocess.rst and the module itself) 
need to also reflect this change

----------
nosy: +pjenvey

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

From report at bugs.python.org  Fri Sep  4 04:51:18 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 04 Sep 2009 02:51:18 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1252032678.55.0.842110336737.issue5329@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Hey Philip,

I'm not sure I follow.  The patch only changes the os module, not the
subprocess module.  What subprocess documentation do you think needs to
be updated?

----------

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

From report at bugs.python.org  Fri Sep  4 04:59:44 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 04 Sep 2009 02:59:44 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1252033184.7.0.0384117141127.issue5329@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

Sorry, I meant the docs describing how to convert os.popen* calls to 
subprocess calls. They assume the shell arg is always True regardless of 
the cmd arg type. Those docs are probably the original source of this bug

----------

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

From report at bugs.python.org  Fri Sep  4 07:01:25 2009
From: report at bugs.python.org (Jerzy)
Date: Fri, 04 Sep 2009 05:01:25 +0000
Subject: [issue6832] Outputting unicode crushes when printing to file on Linux
In-Reply-To: <1252008780.91.0.422465026666.issue6832@psf.upfronthosting.co.za>
Message-ID: <4AA09F08.9070901@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

good point!

I will give it a try

Jerzy

Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> If you want to switch to a different language, consider switching to
> Python 3. There, all strings are Unicode strings, and files opened in
> text mode always use the locale encoding.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6832>
> _______________________________________
>
>
>
>

----------

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

From report at bugs.python.org  Fri Sep  4 07:04:32 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Fri, 04 Sep 2009 05:04:32 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1252040672.8.0.144123159802.issue6824@psf.upfronthosting.co.za>


Ritesh Raj Sarraf <rrs at researchut.com> added the comment:

Take "help os" or "help os.fork" for example.

WIth the help output that they provide, how am I supposed to know that
os.fork is only supported on Unix.

We can also go with the assumption that the modules shipped are
cross-platform. But then, for those that aren't, I don't think we mention
that in the help file documentation.

----------

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

From report at bugs.python.org  Fri Sep  4 08:10:55 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 04 Sep 2009 06:10:55 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1252044655.92.0.0549362149651.issue6834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Let me first explain in more detail why pythonw is needed in the first 
place: MacOSX only allows access to a large number of GUI-related APIs 
from application bundles (the symbols are of course always available, 
but the APIs fail when you are calling them from an executable that is 
not in an application bundle)

This is why we introduced pythonw in framework builds of Python. Pythonw 
is a small executable that does nothing else but execv the real python 
interpreter that is in and .app bundle inside the Python framework 
(Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Pytho
n). The full path to the execv-ed interpreter is hardcoded into the 
pythonw executable.

To be able to switch between 32-bit and 64-bit versions of Python a 4-
way universal build of Python creates 3 variations of the Python 
executable inside the .app bundle: Python-32, Python-64 and Python (the 
latter being 4-way universal).  There are also 3 variations of the 
pythonw executable (such as pythonw-32) that execv the proper version of 
the interpreter.

Using posix_spawn and the other API's I mention it should be fairly easy 
to create a simpler situation where we need only one copy of Python in 
the .app bundle, with the pythonw wrapper selecting the required 
architecture(s) before executing the real interpreter.

Making pythonw fully reusable by virtualenv requires some more work, and 
requires more support code in virtualenv itself as well. One fairly easy 
way to accomplish easy reusability without requiring a C compiler is to 
use a large buffer for storing the path to the real interpreter, 
virtualenv could then patch the executable. 

Another option is to link the pythonw executable to Python.framework and 
then use dyld APIs to find the path to the Python framework and from 
that the executable.

As an aside, virtualenv copies the shared library in Python.framework 
into virtual environments, this is needed because the framework build 
uses the location of that shared library to determine sys.prefix.

----------

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

From report at bugs.python.org  Fri Sep  4 08:37:41 2009
From: report at bugs.python.org (Daniel Black)
Date: Fri, 04 Sep 2009 06:37:41 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1252046261.41.0.4872115721.issue5639@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

Hey Phil,
> (Sorry for dropping this, lost available time)
know the feeling :-(

> use of SNI needs to be something that can be disabled
maybe. See small rational below:

> and people need to be able to connect to host A while supplying host B
This seems to be a fringe case for usage and I seem to thing adding this
would overly complicate the API. When testing hosts you would have all
the names in DNS I'd assume.

> Unless s.connect() gains a keep_original_hostname=False option (?),
this is hard to do.
Is this starting to look too complicated?

Options for client side SNI:
1. wrapssl() - defaults to SNI enabled on SSL2/TLS1 connections (compile
time/module level/object variable disable if really needed?)
2. wrapssl(server_hostname=True/False) - enable SNI using the connect
hostname (if domainname and not IP/socket)
3. wrapssl(server_hostname=True/False/String) - True - enable SNI as
above, False/None- don't use SNI or use hostname if a String.
4. wrapssl(server-hostname=String)
5. connect() should an override_server_hostname=False
more?

> Then there's the principle of least surprise -- while it would be nice
to get SNI working automatically for everyone, it's still plausible that
amongst the various TLS servers out there are some which break horribly
for SNI and upgrading Python shouldn't break the tools in use.

Small rational to enable SNI by default:
1. SNI probably won't break too much stuff.
It was only in July 2009 that Apache-2.2.12 got officially released with
proper SNI support. Patches existed before then however deployment was
limited. mod_gnutls did implemented this earlier however I never thought
this was widely used.
Vista IE7 got SNI support in ~2005
(http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx)
FF got SNI support in the 2.0 release (October 24, 2006, wikipedia) 
(https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26)
The OpenSSL server side API for SNI required the registration of a
callback to receive the SNI name. It is possible that there are some
faulty implementations in this part of the server code. The default case
that a TLS server doesn't account for SNI is very safe as it won't ever
get a callback for it.
The existence of wide spread client side support with limited server
support hasn't broken the web.

> So I tend towards favouring "make use of the newer, less well tested, 
protocol feature something that has to be explicitly enabled", even if 
it adds a line to boilerplate -- if SNI ever takes over the world (as 
Host: headers in HTTP have) then it can be defaulted on in future 
perhaps?

2. I think with p3k there is an opportunity to put something in that may
break stuff. The release noted didn't guarantee stuff would work compatibly.

3. supporting SNI clients by default may actually break less stuff that
not supporting SNI client. e.g. Webhosting companies may embrace the SNI
features of Apache for maximum IP utilization breaking the non-SNI aware
clients (which won't be the majority of web browsers).

> With checking for an IP address?
To be RFC compliant IP addresses shouldn't be used in SNI. Apart from
socket family checking (AF_INET/AF_INET6) and doing a regex on the name
I couldn't see an easy way to do this even looking at the low level
socketmodule.c file. Maybe I need to look deeper. I could cheat and look
at the Firefox crypto (NSS) code though.

just my current thoughts

----------

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

From report at bugs.python.org  Fri Sep  4 08:52:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 06:52:19 +0000
Subject: [issue2649] poss. patch for fnmatch.py to add {.htm,
	html} style globbing
In-Reply-To: <1208433404.5.0.648159158993.issue2649@psf.upfronthosting.co.za>
Message-ID: <1252047139.92.0.441727316091.issue2649@psf.upfronthosting.co.za>


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

Yes, I think that's fine.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> zsh-style subpattern matching for fnmatch/glob

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

From report at bugs.python.org  Fri Sep  4 08:59:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 06:59:30 +0000
Subject: [issue2666] webbrowser.py doesn't properly handle BROWSER env var
In-Reply-To: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>
Message-ID: <1252047570.35.0.454692221855.issue2666@psf.upfronthosting.co.za>


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

Thanks, applied in r74643.

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

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

From report at bugs.python.org  Fri Sep  4 09:31:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Sep 2009 07:31:26 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1252049486.01.0.936788101235.issue6824@psf.upfronthosting.co.za>


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

What makes you think that the tempfile module is not cross-platform?

----------

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

From report at bugs.python.org  Fri Sep  4 09:55:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 07:55:33 +0000
Subject: [issue5047] Remove Monterey support from configure.in
In-Reply-To: <20090124214044.37BA7D56A89@montanaro.dyndns.org>
Message-ID: <1252050933.33.0.966850679858.issue5047@psf.upfronthosting.co.za>


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

Committed in r74644.

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

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

From report at bugs.python.org  Fri Sep  4 09:56:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 07:56:43 +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: <1252051003.78.0.0242126267195.issue5064@psf.upfronthosting.co.za>


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

In light of

> The compiler package is deprecated in favor of builtin AST.

and

> It seems a patch would be an enormous undertaking,

I guess it's best to close this as "won't fix".

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

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

From report at bugs.python.org  Fri Sep  4 09:57:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 07:57:50 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1252051070.91.0.585877250371.issue5080@psf.upfronthosting.co.za>


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

+1.

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

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

From report at bugs.python.org  Fri Sep  4 09:58:21 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Fri, 04 Sep 2009 07:58:21 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1252051101.6.0.309143649892.issue6824@psf.upfronthosting.co.za>


Ritesh Raj Sarraf <rrs at researchut.com> added the comment:

I never said that I think it is not cross-platform.

My point is, it should be good to list down a module's dependency in the
python help docs.

Like:
tempfile

Supported Platforms: ALL
Exception: On Platform foo, feature tempfile.bar() is not available.

----------

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

From report at bugs.python.org  Fri Sep  4 10:02:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 08:02:50 +0000
Subject: [issue977470] Deleted files are reinstalled
Message-ID: <1252051370.91.0.0470900339302.issue977470@psf.upfronthosting.co.za>


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

Closing as "won't fix".

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

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

From report at bugs.python.org  Fri Sep  4 10:07:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 08:07:48 +0000
Subject: [issue5221] help  related topic doesn't exist
In-Reply-To: <1234385289.6.0.0960868675321.issue5221@psf.upfronthosting.co.za>
Message-ID: <1252051668.14.0.237960699496.issue5221@psf.upfronthosting.co.za>


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

Thanks, fixed in r74645.

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

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

From report at bugs.python.org  Fri Sep  4 10:17:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 08:17:18 +0000
Subject: [issue5275] BaseCookie.load doesn't create Morsel objects for mappings
In-Reply-To: <1234738191.23.0.342275234869.issue5275@psf.upfronthosting.co.za>
Message-ID: <1252052238.7.0.118799517969.issue5275@psf.upfronthosting.co.za>


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

Thanks, fixed in r74647.

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

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

From report at bugs.python.org  Fri Sep  4 10:31:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 08:31:11 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252053071.9.0.991112617387.issue6829@psf.upfronthosting.co.za>


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

You'll get a similar message when trying to inherit from e.g. a string
or an int.  I see no compelling reason to special-case functions here.

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

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

From report at bugs.python.org  Fri Sep  4 12:17:27 2009
From: report at bugs.python.org (clemens pecinovsky)
Date: Fri, 04 Sep 2009 10:17:27 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1252059447.66.0.222476600136.issue1208304@psf.upfronthosting.co.za>


clemens pecinovsky <clemens.pecinovsky at gmx.at> added the comment:

i also ran into the problem of cyclic dependencies. i know if i would
call gc.collect() the problem would be solved, but calling gc.collect()
takes a long time. 

the problem is the cyclic dependency with
r.recv=r.read

i have fixed it localy by wrapping the addinfourl into a new class (i
called it addinfourlFixCyclRef) and overloading the close method, and
within the close method set the recv to none again.

class addinfourlFixCyclRef(addinfourl):
    def close(self):
        if self.fp is not None and hasattr(self.fp, "_sock"):
            self.fp._sock.recv = None
        addinfourl.close(self)

....

        r.recv = r.read
        fp = socket._fileobject(r, close=True)

        resp = addinfourlFixCyclRef(fp, r.msg, req.get_full_url())


and when i call .close() from the response it just works. Unluckily i
had to patch even more in case there is an exception called.
For the whole fix see the attachment

----------
nosy: +peci
Added file: http://bugs.python.org/file14827/urllib2.py

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

From report at bugs.python.org  Fri Sep  4 13:18:40 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Sep 2009 11:18:40 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1252063120.48.0.220892604462.issue2576@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Yep, having done some more extensive profiling, it looks like my issue is 
different: all the time is being spent in httplib's 
HTTPResponse._read_chunked. That wouldn't be a symptom of this issue, 
would it?

----------

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

From report at bugs.python.org  Fri Sep  4 13:21:05 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 11:21:05 +0000
Subject: [issue5101] test_funcattrs truncated during unittest conversion
In-Reply-To: <1233263058.35.0.644658374842.issue5101@psf.upfronthosting.co.za>
Message-ID: <1252063265.22.0.630528115716.issue5101@psf.upfronthosting.co.za>


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

Fixed in r74650, r74651 (3k).

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

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

From report at bugs.python.org  Fri Sep  4 13:25:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 11:25:49 +0000
Subject: [issue6756] ftplib documentation does not document what the acct
	parameter is used for
In-Reply-To: <1250857079.39.0.656921992491.issue6756@psf.upfronthosting.co.za>
Message-ID: <1252063549.81.0.254856925761.issue6756@psf.upfronthosting.co.za>


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

Thanks, fixed in r74652.

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

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

From report at bugs.python.org  Fri Sep  4 13:27:52 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 11:27:52 +0000
Subject: [issue5365] add conversion table to time module docs
In-Reply-To: <1235561043.91.0.296999855786.issue5365@psf.upfronthosting.co.za>
Message-ID: <1252063672.04.0.411525536947.issue5365@psf.upfronthosting.co.za>


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

I don't think that is too helpful; for one thing, the description of
strptime and strftime is too vague.

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

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

From report at bugs.python.org  Fri Sep  4 13:33:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 11:33:43 +0000
Subject: [issue6777] Python 2.6 tutorial still recommends using
	Exception.message attribute
In-Reply-To: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>
Message-ID: <1252064023.65.0.837754811697.issue6777@psf.upfronthosting.co.za>


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

Thanks, corrected in r74653.

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

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

From report at bugs.python.org  Fri Sep  4 13:54:29 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 04 Sep 2009 11:54:29 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>


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

There are instances in python where memory allocated using one api 
(PyMem_*) is freed using the other (PyObject_*).
The provided patch (suggested for submission once we fix all instances) 
illustrates this.
It is sufficient to fire up python_d and "import traceback" to trigger the 
error.

----------
components: Interpreter Core
files: debugmalloc.patch
keywords: patch
messages: 92251
nosy: krisvale, lemburg, ncoghlan
severity: normal
status: open
title: Mismatching use of memory APIs
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14828/debugmalloc.patch

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

From report at bugs.python.org  Fri Sep  4 14:03:44 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 04 Sep 2009 12:03:44 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252065824.23.0.910679015738.issue6836@psf.upfronthosting.co.za>


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

Poking the timbot - this seems like a good idea to me (and it also means
C extension developers would be able to use a debug build of Python to
look for errors in their own use of these APIs).

----------
nosy: +tim_one

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

From report at bugs.python.org  Fri Sep  4 15:23:41 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 04 Sep 2009 13:23:41 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252070621.25.0.0285316241045.issue6836@psf.upfronthosting.co.za>


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

using the debugmalloc patch provided, I found only this one case when 
running the testsuite.
Patch is provided.  It is the simple solution of duplicating the string in 
this case.  A more cumbersome solution would be to allocate the "encoding" 
using PyObject_MALLOC in the first place.  But it doesn't seem the right 
api for arbitrary strings, and it might involve much more work.

----------
Added file: http://bugs.python.org/file14829/parsetok.patch

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

From report at bugs.python.org  Fri Sep  4 16:05:29 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 04 Sep 2009 14:05:29 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

According to http://docs.python.org/library/compiler.html, the compiler
package is deprecated.  However, importing the compiler package does not
emit a deprecation warning.  It should, to convey this information to
people who are actually trying to use the package.

----------
components: Library (Lib)
messages: 92254
nosy: exarkun
severity: normal
status: open
title: Mark the compiler package as deprecated
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  4 16:07:44 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 04 Sep 2009 14:07:44 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252073264.3.0.500321877945.issue6829@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Ok, but why not to change the message to less cryptic 
"Impossible to inherit class from function(), string or int"?

----------

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

From report at bugs.python.org  Fri Sep  4 16:08:39 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 04 Sep 2009 14:08:39 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252073319.34.0.930664898811.issue6829@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
status: closed -> pending

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

From report at bugs.python.org  Fri Sep  4 17:22:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Sep 2009 15:22:05 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252077725.9.0.665889703639.issue6829@psf.upfronthosting.co.za>


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

That would still be special-casing, you'd just be special casing three
things instead of one, nor does that exhaust the list of things for
which you might get this kind of error.

However, the code that generates the error message contains the
following comment:

    /* A type error here likely means that the user passed
       in a base that was not a class (such the random module
       instead of the random.random type).  Help them out with
       by augmenting the error message with more information.*/

So, it seems to me that the author (I think it was Raymond, so I'm
setting him nosy) was trying to give the requested clue, but it sounds
like the error message isn't quite achieving that goal.

I've tried several rephrasings, but I haven't come up with one I'm
completely happy with.  It seems that the most common problem is trying
to use an instance as a base, and if that is correct the best I've come
up with so far is:

    "Error when calling the metaclass bases (specified base may be an
instance instead of a class)"

----------
keywords: +easy
nosy: +r.david.murray, rhettinger
priority:  -> low
status: pending -> open

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

From report at bugs.python.org  Fri Sep  4 17:44:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Sep 2009 15:44:11 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252079051.31.0.487175056854.issue6837@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Sep  4 18:08:42 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Sep 2009 16:08:42 +0000
Subject: [issue6838] httplib's _read_chunked extremely slow for lots of chunks
In-Reply-To: <1252080521.37.0.722122314932.issue6838@psf.upfronthosting.co.za>
Message-ID: <1252080521.37.0.722122314932.issue6838@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

As the comment in this method suggests, accumulating the value by repeated string concatenation is slow. Appending to a list speeds this 
up dramatically.

To quantify this, downloading a 110Mb file from Apache take:

~3s using Internet Explorer
2.2s using wget
30mins using the script in http://mail.python.org/pipermail/python-
dev/2009-September/091581.html

With the attached patch applied, this time drops to 2.3s.

----------
assignee: cjw296
files: httplib.patch.txt
keywords: easy
messages: 92257
nosy: cjw296
priority: high
severity: normal
status: open
title: httplib's _read_chunked extremely slow for lots of chunks
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14830/httplib.patch.txt

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

From report at bugs.python.org  Fri Sep  4 18:12:54 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Sep 2009 16:12:54 +0000
Subject: [issue6838] httplib's _read_chunked extremely slow for lots of chunks
In-Reply-To: <1252080521.37.0.722122314932.issue6838@psf.upfronthosting.co.za>
Message-ID: <1252080774.85.0.110877288759.issue6838@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Fix for trunk committed in r74655.

----------

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

From report at bugs.python.org  Fri Sep  4 19:15:58 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Sep 2009 17:15:58 +0000
Subject: [issue6838] httplib's _read_chunked extremely slow for lots of chunks
In-Reply-To: <1252080521.37.0.722122314932.issue6838@psf.upfronthosting.co.za>
Message-ID: <1252084558.78.0.242469508705.issue6838@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Fix merged to 2.6, 3.1 and 3.2 branches.

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

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

From report at bugs.python.org  Fri Sep  4 19:42:41 2009
From: report at bugs.python.org (Manuel Kaufmann)
Date: Fri, 04 Sep 2009 17:42:41 +0000
Subject: [issue5831] Doc mistake : threading.Timer is *not* a class
In-Reply-To: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
Message-ID: <1252086161.8.0.160844589828.issue5831@psf.upfronthosting.co.za>


Manuel Kaufmann <humitos at gmail.com> added the comment:

I deleted this function and I renamed the class _Timer to Timer. I
attached the patch

----------
keywords: +patch
nosy: +humitos
Added file: http://bugs.python.org/file14831/threading.Issue.5831.patch

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

From report at bugs.python.org  Fri Sep  4 20:39:11 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Sep 2009 18:39:11 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1252089551.01.0.744735900041.issue6239@psf.upfronthosting.co.za>


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

Commited as svn rev 74664 (py3k) and rev 74665 (release31-maint).

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

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

From report at bugs.python.org  Fri Sep  4 20:41:37 2009
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 04 Sep 2009 18:41:37 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1252089697.9.0.3926093122.issue6795@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Issue 1: +1 to raise ValueError

Issue 3: -0 to change actual behaviour

Thanks!

----------

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

From report at bugs.python.org  Fri Sep  4 20:58:41 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Sep 2009 18:58:41 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252090721.09.0.359057328043.issue6837@psf.upfronthosting.co.za>


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

The package is not going to be removed from 2.x at this point since 2.7 
will most likely be the last major release of the line. But it does have a 
Py3k warning which is good enough in this situation.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Sep  4 21:03:31 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Sep 2009 19:03:31 +0000
Subject: [issue6824] help for a module should list supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1252091011.52.0.423858383188.issue6824@psf.upfronthosting.co.za>


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

*most* modules are platform independent, and for those, I do not think
anything needs to be said. 

I agree with OP that it would be nice if interactive help indicated
platform dependencies, if and when such is not done now. I have no idea
if any of such addition could be easily automated.

----------
nosy: +tjreedy
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Fri Sep  4 21:56:50 2009
From: report at bugs.python.org (Kim Kyung Don)
Date: Fri, 04 Sep 2009 19:56:50 +0000
Subject: [issue6839] zipfile can't extract file
Message-ID: <1252094210.03.0.111917894019.issue6839@psf.upfronthosting.co.za>


Changes by Kim Kyung Don <newercookie at gmail.com>:


----------
components: Library (Lib), Windows
files: test.zip
nosy: NewerCookie
severity: normal
status: open
title: zipfile can't extract file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14832/test.zip

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

From report at bugs.python.org  Fri Sep  4 21:57:59 2009
From: report at bugs.python.org (Kim Kyung Don)
Date: Fri, 04 Sep 2009 19:57:59 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>


New submission from Kim Kyung Don <newercookie at gmail.com>:

The following exception occured when I tried to extract on Windows.

"zipfile.BadZipfile: File name in directory "test\test2.txt" and header
"test/test2.txt" differ."

It seems like problem about slash.
I tested using by zipfile Revision 72893.

----------

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

From report at bugs.python.org  Fri Sep  4 22:35:29 2009
From: report at bugs.python.org (=?utf-8?q?Mat=C3=ADas?=)
Date: Fri, 04 Sep 2009 20:35:29 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1252096529.81.0.669525276099.issue1353344@psf.upfronthosting.co.za>


Mat?as <mribecky.registraciones at gmail.com> added the comment:

Added the spanish translation.

----------
nosy: +mribecky
Added file: http://bugs.python.org/file14833/python.desktop

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

From report at bugs.python.org  Fri Sep  4 23:31:44 2009
From: report at bugs.python.org (Alexandru Munteanu)
Date: Fri, 04 Sep 2009 21:31:44 +0000
Subject: [issue6840] genericpath: _splitext returns '.ext', '' instead of '', 
	'.ext'
In-Reply-To: <1252099904.92.0.556344423163.issue6840@psf.upfronthosting.co.za>
Message-ID: <1252099904.92.0.556344423163.issue6840@psf.upfronthosting.co.za>


New submission from Alexandru Munteanu <io_fx at yahoo.fr>:

Having a '.ogg' filename, _splitext returns '.ogg' as base and empty
extension. Probably it should return empty base and '.ogg' extension.

Lib/genericpath.py:99 - Why "skip all leading dots" ?

I attach a possible patch (with tests).

----------
components: Library (Lib)
files: genericpath_splitext.patch
keywords: patch
messages: 92267
nosy: optimix
severity: normal
status: open
title: genericpath: _splitext returns '.ext', '' instead of '', '.ext'
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14834/genericpath_splitext.patch

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

From report at bugs.python.org  Fri Sep  4 23:58:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 04 Sep 2009 21:58:09 +0000
Subject: [issue6840] genericpath: _splitext returns '.ext', '' instead of '', 
	'.ext'
In-Reply-To: <1252099904.92.0.556344423163.issue6840@psf.upfronthosting.co.za>
Message-ID: <1252101489.0.0.361670796353.issue6840@psf.upfronthosting.co.za>


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

Have a look at http://bugs.python.org/issue1115886.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Sat Sep  5 00:09:49 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Sep 2009 22:09:49 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1252102189.22.0.636640067574.issue6703@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Hmm, I don't think tests will fail, however, there are cryptic docs for this...

http://docs.python.org/library/doctest.html#basic-api

I don't really get what module_relative is about and I've always run into the non-
cross-platform issue above when passing an absolute path to DocFileSuite while 
forgetting to specify module_relative=False.

The weird/frustrating thing is that the tests behave *just fine* on Windows with 
module_relative being the default of True and the absolute path being specified, so 
I'm not really sure what difference either the module_relative option or the check 
that the path doesn't start with a / mean...

The problem is that while the docs specify that paths must be /-separated, nothing 
in the code enforces this. 

So, with module_relative as True, the default:

- If you generate and pass an absolute path on Windows, it'll work just fine. 

- If you pass a '\\'-separated module-relative path, this will work just fine.
  (You'll end up with base/dir\path\you\supplied, but I doubt `open` will care about 
that.

With module_relative set to False, I'm not really sure what happens...

Anyone?

----------

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

From report at bugs.python.org  Sat Sep  5 00:16:06 2009
From: report at bugs.python.org (Alexandru Munteanu)
Date: Fri, 04 Sep 2009 22:16:06 +0000
Subject: [issue1115886] os.path.splitext don't handle unix hidden file
	correctly
Message-ID: <1252102566.68.0.256901206152.issue1115886@psf.upfronthosting.co.za>


Alexandru Munteanu <io_fx at yahoo.fr> added the comment:

I've read parts of the python-dev discussions, but I don't agree with
this change:
   mimetypes.guess_type()
now recognises '.ogg' as None.

----------
nosy: +optimix

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

From report at bugs.python.org  Sat Sep  5 00:26:01 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 04 Sep 2009 22:26:01 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252103161.62.0.939623882018.issue6837@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Bugs are no longer being fixed in the compiler package.  To me, that
says it should be regular-deprecated.  People with no short term plans
of switching to Python 3 will still want to avoid the compiler package.
 They should be told about the deprecation too, and they're not going to
be turning on Py3k warnings.

----------

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

From report at bugs.python.org  Sat Sep  5 05:16:10 2009
From: report at bugs.python.org (Phil Pennock)
Date: Sat, 05 Sep 2009 03:16:10 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1252120570.1.0.835890822447.issue5639@psf.upfronthosting.co.za>


Phil Pennock <python-dev at spodhuis.org> added the comment:

wrapssl(server_hostname=True/False/String) looks good to me.

Your arguments for enabling by default are compelling, for P3k.

----------

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

From report at bugs.python.org  Sat Sep  5 10:54:07 2009
From: report at bugs.python.org (Cheese Lee)
Date: Sat, 05 Sep 2009 08:54:07 +0000
Subject: [issue6841] A typo in Doc/library/stdtypes.rst
In-Reply-To: <1252140847.01.0.360605550612.issue6841@psf.upfronthosting.co.za>
Message-ID: <1252140847.01.0.360605550612.issue6841@psf.upfronthosting.co.za>


New submission from Cheese Lee <cheeselee at 126.com>:

See the patch.
This typo is found in all branches.

----------
assignee: georg.brandl
components: Documentation
files: stdtypes-rst-cheese.patch
keywords: patch
messages: 92273
nosy: cheeselee, georg.brandl
severity: normal
status: open
title: A typo in Doc/library/stdtypes.rst
versions: Python 2.6
Added file: http://bugs.python.org/file14835/stdtypes-rst-cheese.patch

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

From report at bugs.python.org  Sat Sep  5 11:04:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Sep 2009 09:04:29 +0000
Subject: [issue6841] A typo in Doc/library/stdtypes.rst
In-Reply-To: <1252140847.01.0.360605550612.issue6841@psf.upfronthosting.co.za>
Message-ID: <1252141469.87.0.286214000766.issue6841@psf.upfronthosting.co.za>


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

Thanks, fixed in r74666, will be merged to other branches soon.

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

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

From report at bugs.python.org  Sat Sep  5 16:44:10 2009
From: report at bugs.python.org (John Van Praag)
Date: Sat, 05 Sep 2009 14:44:10 +0000
Subject: [issue6842] program run in interpreter, fails at command line
In-Reply-To: <1252161850.13.0.448876854396.issue6842@psf.upfronthosting.co.za>
Message-ID: <1252161850.13.0.448876854396.issue6842@psf.upfronthosting.co.za>


New submission from John Van Praag <john at jvp247.com>:

My platform: Win XP.
Program fibo.py from the tutorial runs correctly in the interpreter.
When I run it from the command line I get the following error:

file "fibo.py" line 6
  print(b, end=' ')
              ^

----------
components: Windows
files: fibo.py
messages: 92275
nosy: jvanpraag
severity: normal
status: open
title: program run in interpreter, fails at command line
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14836/fibo.py

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

From report at bugs.python.org  Sat Sep  5 16:51:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Sep 2009 14:51:10 +0000
Subject: [issue6842] program run in interpreter, fails at command line
In-Reply-To: <1252161850.13.0.448876854396.issue6842@psf.upfronthosting.co.za>
Message-ID: <1252162270.24.0.254756927882.issue6842@psf.upfronthosting.co.za>


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

You're probably trying to run it under Python 2.5 or Python 2.6 instead of 
Python 3.1.  The line you show only makes sense for Python 3.x.

You code runs fine for me (using python3.1, on OS X 10.5).

----------
nosy: +marketdickinson
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Sat Sep  5 16:59:45 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Sep 2009 14:59:45 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1252162785.24.0.902903011467.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've made two subsequent patches. I found after reading the symlink
documentation that I had gotten the parameters mixed up.

This patch, tagged r4274, addresses that issue.

----------
Added file: http://bugs.python.org/file14837/python-core_rev4274.patch

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

From report at bugs.python.org  Sat Sep  5 17:01:54 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Sep 2009 15:01:54 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1252162914.62.0.413114937523.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This second patch adds the documentation to os.rst to formally define
the behavior of the symlink function in Windows. Only changes needed to
be made to the lstat and symlink functions.  readlink remains Unix-only.
We may consider implementing this method for Windows as well at a later
date.

----------
Added file: http://bugs.python.org/file14838/python-core_rev4275.patch

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

From report at bugs.python.org  Sat Sep  5 17:12:49 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 15:12:49 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1252163569.35.0.0748642844437.issue5329@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


Added file: http://bugs.python.org/file14839/subprocess-conversion-doc.patch

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

From report at bugs.python.org  Sat Sep  5 17:13:19 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 15:13:19 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1252163599.26.0.641027097312.issue5329@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Ah, thanks for the clarification, Philip.  I've attached another patch
updating those docs.

----------

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

From report at bugs.python.org  Sat Sep  5 17:44:30 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 15:44:30 +0000
Subject: [issue6843] No documentation for the module argument to
	warnings.filterwarnings
In-Reply-To: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>
Message-ID: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

None of the documentation seems to cover this parameter.  The test suite
doesn't even seem to exercise it, either.  What does it do?  What kind
of values are expected to be passed for it?

----------
assignee: georg.brandl
components: Documentation
messages: 92280
nosy: exarkun, georg.brandl
severity: normal
status: open
title: No documentation for the module argument to warnings.filterwarnings
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Sep  5 18:24:54 2009
From: report at bugs.python.org (Alan Isaac)
Date: Sat, 05 Sep 2009 16:24:54 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>


New submission from Alan Isaac <alan.isaac at gmail.com>:

In Python 2.6 if I subclass Exception and intialize my instances with a
`message` attribute, I get a DeprecationError via BaseException.

Of course there is no problem in Py3, because adding a `message`
attribute to instances of a subclass is in fact **not** a problem and
will **not** be disallowed.  I.e., the DeprecationError is raised
incorrectly in Python 2.6.

I am not sure how to raise a DeprecationError *only* in the correct
cases, but certainly the current behavior can be much improved.  As a
crude example, if the `args` passed to BaseException has length 0, then
a flag could be set not to raise this DeprecationError.  Even if not
perfect, this would be **much** better than the current behavior, since
it is common practice not to pass the subclass's initialization
arguments on to Exception.__init__.

This behavior can be expected to affect entire libraries and therefore
should be fixed.  (Eg., it affects docutils.)  I.e., "change the name of
your variable" is the wrong answer to this bug report.

----------
components: Interpreter Core
messages: 92281
nosy: aisaac
severity: normal
status: open
title: BaseException DeprecationError raises inappropriately
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Sep  5 18:47:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Sep 2009 16:47:25 +0000
Subject: [issue6843] No documentation for the module argument to
	warnings.filterwarnings
In-Reply-To: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>
Message-ID: <1252169245.41.0.96107710096.issue6843@psf.upfronthosting.co.za>


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

The values for a filter entry are documented under the "The Warnings
Filter" heading.  I've added a link to it from filterwarnings in r74671.

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

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

From report at bugs.python.org  Sat Sep  5 19:08:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Sep 2009 17:08:16 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252170496.38.0.560310721188.issue6837@psf.upfronthosting.co.za>


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

The compiler package is surprisingly often used; we already had
complaints when (I think) 2.6 began emitting lots of new
DeprecationWarnings, but for modules/APIs whose replacements was
straightforward.

Replacing usage of the compiler package is usually not straightforward,
since the AST differs from Python's own, and the API for accessing it
even more.  This means that lots of code will continue spewing out these
warnings.

However, a more visible notice in the docs would not hurt, I guess.

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

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

From report at bugs.python.org  Sat Sep  5 19:48:55 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 17:48:55 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252172935.52.0.0255005216579.issue6837@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Hi Georg, thanks for your comment.

I'm not sure I fully understand, though.

The compiler package is widely used, okay.  So I suppose that means that
the desire here is to make those users happy?

But the compiler package is deprecated, and has known bugs which will
not be fixed.

But to avoid making people unhappy, using the compiler package shouldn't
emit a deprecation warning (despite the fact that it is deprecated). 
Because... seeing the message will make people unhappy?  In contract
specifically to the fact that bugs in the package are going to remain
unfixed and a replacement is being put forward.  It's the message that
is going to cause the upset?

Thanks for any clarification.

----------

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

From report at bugs.python.org  Sat Sep  5 19:49:44 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 17:49:44 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252172984.93.0.661616843968.issue6837@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Oops.  I wrote "In contract" in my previous message.  I meant "In contrast".

----------

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

From report at bugs.python.org  Sat Sep  5 19:57:56 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 17:57:56 +0000
Subject: [issue6843] No documentation for the module argument to
	warnings.filterwarnings
In-Reply-To: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>
Message-ID: <1252173476.49.0.418994045744.issue6843@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Thanks for that Georg.

I'm still having trouble with this.  I'm aware that the issue tracking
isn't the right place to ask for help with writing programs, but I think
that since I still can't get this code to work, even looking at the new
documentation, there is still a documentation issue.  Perhaps there's
something else I'm doing wrong, though.

The code causing the warning to be emitted is here:

http://twistedmatrix.com/trac/browser/trunk/twisted/conch/ssh/filetransfer.py?rev=27062#L829

It's a simple example of the new-in-2.6 BaseException.message
deprecation warning.  I'm trying to suppress this.  My attempt goes
something like this:

warnings.filterwarnings(
    'ignore',
    message='BaseException.message has been deprecated as of Python 2.6',
    category=DeprecationWarning,
    module=r'twisted\.conch\.ssh\.filetransfer')

When I remove the module argument from this call, the warning is
suppressed.  When I include it, it is not.  The string given seems to be
"a string containing a regular expression that the module name must
match", the meaning the documentation suggests.  Am I just doing
something wrong, or are the docs still not right?

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

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

From report at bugs.python.org  Sat Sep  5 20:00:45 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Sat, 05 Sep 2009 18:00:45 +0000
Subject: [issue6845] ftplib rest support for storbinary
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>


New submission from Pablo Mouzo <pablomouzo at gmail.com>:

FPT class doesn't support the rest parameter in storbinary method.

----------
components: None
messages: 92287
nosy: pablomouzo
severity: normal
status: open
title: ftplib rest support for storbinary
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep  5 20:07:37 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Sep 2009 18:07:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1252174057.6.0.14261816436.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After a short time and some more learning about Mercurial, I discovered
how to rebase my local repository and create a new unified diff against
the latest py3k branch.  This latest patch (7) supercedes all previous
patches.

I hope this patch is suitable for painless merging into the py3k branch.

Eric, please let me know if you encounter any trouble merging it.

----------
Added file: http://bugs.python.org/file14840/windows symlink draft 7.patch

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

From report at bugs.python.org  Sat Sep  5 20:38:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Sep 2009 18:38:04 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252175884.92.0.301256876474.issue6837@psf.upfronthosting.co.za>


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

"Bugs are not fixed" is somewhat misleading -- I assume you're referring
to bugs like the one I closed recently. Those are all bugs that have
been in the compiler package for ages, and users that hit them know them
or work around them.  If a regression comes up, it should be fixed IMO.

The only way to make the compiler users happy would be to add it back,
fully supported, to Python3 :)

If you want to understand my reasoning: I want to avoid a situation like
a few months ago, when Python 2.6 was released -- people claimed e.g.
the latest Mercurial release at that time wasn't compatible with 2.6
because it emitted quite a few DeprecationWarnings.  This statement is
not true, of course, but this is how users see it.  In that case, it was
easy for Mercurial to "fix" because all the deprecated features could be
replaced without effort.  For libraries/programs that use the compiler
package, this won't be effortless and many maintainers may not be able
to spend the time and effort to "fix" that.

Also, if you look at other modules removed in Py3k, like "new" or
"rfc822", they all only raise a Py3k deprecation warning.

----------

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

From report at bugs.python.org  Sat Sep  5 20:42:36 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Sat, 05 Sep 2009 18:42:36 +0000
Subject: [issue6845] ftplib rest support for storbinary
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1252176156.19.0.256819114567.issue6845@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

I attached a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file14841/issue6845.patch

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

From report at bugs.python.org  Sat Sep  5 20:45:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Sep 2009 18:45:03 +0000
Subject: [issue6843] No documentation for the module argument to
	warnings.filterwarnings
In-Reply-To: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>
Message-ID: <1252176303.76.0.284219064499.issue6843@psf.upfronthosting.co.za>


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

A simple isolated test here shows that the module argument works as
intended.  I can't help with your problem without more information (but
you probably should debug this somewhere in warnings.py/_warnings.c). 
But you're right, this is not a subject for the bugtracker anymore :)

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

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

From report at bugs.python.org  Sat Sep  5 20:51:56 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 05 Sep 2009 18:51:56 +0000
Subject: [issue6846] bytearray.pop() returns negative ints
In-Reply-To: <1252176716.07.0.102651567862.issue6846@psf.upfronthosting.co.za>
Message-ID: <1252176716.07.0.102651567862.issue6846@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

This looks pretty bad:

>>> b = bytearray(b"\xff")
>>> b[0]
255
>>> b.pop()
-1

Fortunately it's easy too fix (attached).

----------
components: Interpreter Core
messages: 92292
nosy: hagen
severity: normal
status: open
title: bytearray.pop() returns negative ints
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep  5 20:53:07 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 05 Sep 2009 18:53:07 +0000
Subject: [issue6846] bytearray.pop() returns negative ints
In-Reply-To: <1252176716.07.0.102651567862.issue6846@psf.upfronthosting.co.za>
Message-ID: <1252176787.24.0.723855112869.issue6846@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14842/bytearray.patch

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

From report at bugs.python.org  Sat Sep  5 20:59:54 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 05 Sep 2009 18:59:54 +0000
Subject: [issue6847] Exception strings for bytearray say "bytes"
In-Reply-To: <1252177194.86.0.89360876667.issue6847@psf.upfronthosting.co.za>
Message-ID: <1252177194.86.0.89360876667.issue6847@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Various exceptions thrown by bytearray objects talk of "bytes" instead
of "bytearray". Correction attached.

----------
components: Interpreter Core
files: bytearray_strings.patch
keywords: patch
messages: 92293
nosy: hagen
severity: normal
status: open
title: Exception strings for bytearray say "bytes"
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14843/bytearray_strings.patch

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

From report at bugs.python.org  Sat Sep  5 21:27:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Sep 2009 19:27:16 +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: <1252178836.95.0.940019967294.issue3366@psf.upfronthosting.co.za>


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

Finally got around to looking at this properly.

Here's a first attempt at a patch to add gamma, lgamma, erf and erfc to 
the math module.  It uses the pymath.c.diff code from nirinA, and adds 
docs, tests, and the extra infrastructure needed for the build system.

The code has gone in a new file called Modules/math_cextra.c.  The old 
approach of sticking things in pymath.c really isn't right, since that 
ends up putting the extra code into the core Python executable instead 
of the math module.

There are currently many test failures;  some of these are undoubtedly 
due to the tests being too strict, but some of them show problems with 
the code for these functions.  It should be possible to have erf and 
erfc produce results accurate to within a few ulps (<50, say) over the 
entire extended real line;  getting gamma and lgamma accurate for 
positive inputs should also be perfectly possible.  Negative arguments 
seem to be more difficult to get right.

To test the code on non-Windows, build with something like:

CC='gcc -DTEST_GAMMA' ./configure && make

the '-DTEST_GAMMA' just forces the build to use nirinA's code;  without 
this, the math module will use the libm functions if they're available.

This is just work-in-progress;  apart from the test failures, there's 
still a lot of polishing to do before this can go in.

The patch is against the trunk.

----------
versions: +Python 3.2 -Python 3.1
Added file: http://bugs.python.org/file14844/gamma.patch

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

From report at bugs.python.org  Sat Sep  5 22:15:42 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 20:15:42 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252181742.85.0.323848084879.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This also affects Twisted.  We worked around it a couple months ago by
putting a read-only `message` property onto our Exception subclass
(Here's the revision: <http://twistedmatrix.com/trac/changeset/27062>).
 This seemed reasonable enough, but it turns out that it's incompatible
with PyPy so we'll probably have to do something else instead.

----------
nosy: +exarkun

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

From report at bugs.python.org  Sat Sep  5 23:03:18 2009
From: report at bugs.python.org (ivank)
Date: Sat, 05 Sep 2009 21:03:18 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252184598.57.0.237957991257.issue6844@psf.upfronthosting.co.za>


ivank <ivan at ludios.org> added the comment:

That trac link should be http://twistedmatrix.com/trac/changeset/27062

----------
nosy: +ivank

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

From report at bugs.python.org  Sun Sep  6 06:02:03 2009
From: report at bugs.python.org (Kim Kyung Don)
Date: Sun, 06 Sep 2009 04:02:03 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252209723.21.0.539519611236.issue6839@psf.upfronthosting.co.za>


Kim Kyung Don <newercookie at gmail.com> added the comment:

P.S
I tested extraction by using 7-zip.
It works fine.

----------

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

From report at bugs.python.org  Sun Sep  6 11:48:59 2009
From: report at bugs.python.org (Tim Peters)
Date: Sun, 06 Sep 2009 09:48:59 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252230539.27.0.0539255315852.issue6836@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Yup, it's a good idea.  In fact, storing info in the debug malloc blocks
to identify the API family used was part of "the plan", but got dropped
when time ran out.

serialno should not be abused for this purpose, though.  On a 32-bit
box, a 24-bit real serialno is too small.  Mucking with serialno also
breaks the current straightforward use of data breakpoints (under
systems that support those) to rerun a deterministic program until a
specific value for serialno is reached.

The original intent was to use one of "forbidden" pad bytes for this
purpose, either the last one following the block or the first one
preceding the block.  That wouldn't interfere with anything, and the
code would be substantially simpler (no endless shifting and masking
needed when a byte's worth of data is stored /in/ a byte).

In any case, internal comments must document the possible values for the
"id" and their meanings.  It's just plain cruel to make the code reader
leap all over the code trying to reverse-engineer the intent ;-)

----------

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

From report at bugs.python.org  Sun Sep  6 12:21:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 10:21:08 +0000
Subject: [issue6846] bytearray.pop() returns negative ints
In-Reply-To: <1252176716.07.0.102651567862.issue6846@psf.upfronthosting.co.za>
Message-ID: <1252232468.58.0.533226613494.issue6846@psf.upfronthosting.co.za>


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

Fixed in r74673 (trunk), r74674 (release26-maint), r74675 (py3k)
and r74676 (release31-maint).  Thanks!

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

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

From report at bugs.python.org  Sun Sep  6 12:36:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 10:36:48 +0000
Subject: [issue6847] Exception strings for bytearray say "bytes"
In-Reply-To: <1252177194.86.0.89360876667.issue6847@psf.upfronthosting.co.za>
Message-ID: <1252233408.89.0.65427454686.issue6847@psf.upfronthosting.co.za>


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

Thanks.  Fixed in revisions r74677 through r74680.

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

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

From report at bugs.python.org  Sun Sep  6 13:11:31 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 11:11:31 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252235491.71.0.1663927541.issue6802@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r74672 (trunk), r74681 (2.6), r74682 (3.x) and r74683 (3.1)

With the default configure flags you'll end up with a 64-bit build of 
Python on Snow Leopard, including a 64-bit copy of IDLE.

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

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

From report at bugs.python.org  Sun Sep  6 14:05:52 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:05:52 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1252238752.88.0.317725531369.issue6245@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a new patch "arch-intel-v2.patch" that relects my current 
thinking about this patch.

This adds two new options to the "--with-univeral-archs" option for 
configure: "intel" and "3-way". The former builds a universal binary 
with the i386 and x86_64 architectures, the latter builds one with the 
i386, x86_64 and ppc architectures.

The "intel" build is most useful when your code only needs to run on 
modernish systems, the latter allows you to run scripts on PPC systems 
as well.

Both can be build on Snow Leopard systems. The current options "all" and 
"64-bit" cannot be used when you perform your build and target the 
default SDK because the system doesn't ship with PPC64 suppport anymore.

I intend to apply this patch for 2.7 and 3.2 unless there is serious 
opposition against this. The patch will not be backported to earlier 
versions.

----------
Added file: http://bugs.python.org/file14845/arch-intel-v2.patch

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

From report at bugs.python.org  Sun Sep  6 14:10:13 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:10:13 +0000
Subject: [issue6812] Snow Leopard python program fails because
	_PyType_Modified is missing from python framework
In-Reply-To: <1251757214.1.0.925595604794.issue6812@psf.upfronthosting.co.za>
Message-ID: <1252239013.92.0.217355282717.issue6812@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This seems to be a problem with Apple's copy of Python or with your 
machine.

Could you try the following:
* In terminal.app run /usr/bin/python
* Then use 'import objc' from Python's prompt.
* Does this work or does it give the same traceback (it works for me 
BTW).

If importing objc from Python's prompt works: Try to do a clean build of 
the application in Xcode (use Clean All and then perform a build).

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

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

From report at bugs.python.org  Sun Sep  6 14:11:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:11:49 +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: <1252239109.76.0.887583403869.issue5514@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this issue because the user does not respond to my questions 
and because I don't agree there is a problem.

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

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

From report at bugs.python.org  Sun Sep  6 14:13:47 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:13:47 +0000
Subject: [issue6552] Build Applet.app
In-Reply-To: <1248328554.77.0.248074125198.issue6552@psf.upfronthosting.co.za>
Message-ID: <1252239227.77.0.152198524734.issue6552@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Build Applet is not present in Python 3 because the implementation uses 
Python modules that aren't present in Python 3 (in particular the long 
deprecated Carbon bindings).

The best alternative to the Build Applet functionality is py2app, but that 
is sadly not ported to Python 3 yet.

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

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

From report at bugs.python.org  Sun Sep  6 14:14:47 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:14:47 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1252239287.41.0.57995906597.issue6441@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I found an easier way to test with a 64-bit Tcl/Tk: run Snow Leopard ;-)

----------

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

From report at bugs.python.org  Sun Sep  6 14:27:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:27:19 +0000
Subject: [issue4937] Mac DMG install missing version.plist required by
	bundlebuilder.py
In-Reply-To: <1231880551.46.0.128485851272.issue4937@psf.upfronthosting.co.za>
Message-ID: <1252240039.51.0.0679471878855.issue4937@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This will be fixed in the next release of 2.6 and 2.7: bundlebuilder 
shouldn't have tried to copy version.plist in the first place.

The actual revisions in which this was fixed: r74684 (trunk), r74685 (2.6)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Sun Sep  6 14:38:31 2009
From: report at bugs.python.org (Joshua Root)
Date: Sun, 06 Sep 2009 12:38:31 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252240711.78.0.765176210456.issue6802@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

I tried release26-maint just now (r74683) and it errored out during make 
install. New log attached.

----------
Added file: http://bugs.python.org/file14846/release26-maint.log

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

From report at bugs.python.org  Sun Sep  6 14:40:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:40:07 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252240807.46.0.0192906738183.issue6839@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The zipfile is technically incorrect, the zipfile specification prescribes 
that all filenames use '/' as the directory separator.

Even without that caveat the file is corrupt because the zipfile directory 
header and the per-file header don't agree on the name of the file.

That said: IMHO the current code in zipfile.ZipFile.open is too strict, it 
shouldn't raise an error when the two names aren't exactly the same 
because there are valid reasons for them to be different (such as renaming 
a file in the zipfile without rewriting the entire zipfile).

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Sep  6 14:41:38 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 12:41:38 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252240898.38.0.748447897023.issue6802@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Could you retry the build after cleaning the target directory?

I've seem simular failures in the past and haven't been able to find the 
root cause of that problem.

----------

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

From report at bugs.python.org  Sun Sep  6 14:51:21 2009
From: report at bugs.python.org (Joshua Root)
Date: Sun, 06 Sep 2009 12:51:21 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252241481.97.0.213277174411.issue6802@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

Tried again after ensuring that ~/test was completely empty; no 
difference.

----------

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

From report at bugs.python.org  Sun Sep  6 14:53:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 12:53:32 +0000
Subject: [issue6848] curses module build failure (ncurses 5.7)
In-Reply-To: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>
Message-ID: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>


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

There seems to be a problem building the curses module on systems with 
ncurses 5.7.  The following output was produced on OS X 10.6, on a trunk 
build;  I'm not sure whether this problem is Mac-specific (or 64-bit 
specific).

building '_curses' extension
gcc -fno-strict-aliasing -g -Wall -Wstrict-prototypes -
I/Users/dickinsm/python/svn/trunk/Mac/Include -I. -I./Include -IInclude 
-I/Users/dickinsm/python/svn/trunk -c 
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c -o 
build/temp.macosx-10.4-i386-2.7-
pydebug/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.o
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
?PyCursesWindow_EchoChar?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:805: error: 
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:812: warning: 
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
?PyCursesWindow_NoOutRefresh?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1230: error: 
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1261: warning: 
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
?PyCursesWindow_Refresh?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1372: error: 
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1402: warning: 
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
?PyCursesWindow_SubWin?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1438: error: 
dereferencing pointer to incomplete type

Here's a relevant excerpt from _cursesmodule.c (lines 804--811)

#ifdef WINDOW_HAS_FLAGS
  if (self->win->_flags & _ISPAD)
    return PyCursesCheckERR(pechochar(self->win, ch | attr),
                            "echochar");
  else
#endif
    return PyCursesCheckERR(wechochar(self->win, ch | attr),
                            "echochar");

Here self->win has type WINDOW;  the problem is that as of ncurses 5.7, the internals of the WINDOW type (and much else besides) are deliberately hidden (by default) from users of the library;  there's a 
preprocessor constant NCURSES_OPAQUE that controls this.

So an obvious workaround is to set NCURSES_OPAQUE=0 somewhere in the 
Python build process;  however, that may be the wrong thing to do if the ncurses developers are planning to mess with the ncurses internals in 
the near future (which would explain the NCURSES_OPAQUE business).  I 
don't know whether there's some alternative 'official' way to 
distinguish between ncurses windows and pads.

----------
components: Build
messages: 92312
nosy: marketdickinson
severity: normal
status: open
title: curses module build failure (ncurses 5.7)
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep  6 15:05:58 2009
From: report at bugs.python.org (Joshua Root)
Date: Sun, 06 Sep 2009 13:05:58 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252242358.03.0.217208805138.issue6802@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

Should line 110 of Lib/plat-mac/macresource.py say 'isinstance' rather 
than 'instance'?

----------

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

From report at bugs.python.org  Sun Sep  6 15:06:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 13:06:10 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252242370.74.0.592813548038.issue6802@psf.upfronthosting.co.za>


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

Looks like there's a spurious comma in line 110 of lib/plat-
mac/macresource.py in the release26-maint branch:

        if instance(arg, AttributeError), or arg[0] in (-37, -39):

----------

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

From report at bugs.python.org  Sun Sep  6 15:08:12 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 13:08:12 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252242492.73.0.648916793267.issue6802@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

You're right. I've fixed this in r74686.

----------

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

From report at bugs.python.org  Sun Sep  6 15:21:18 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 13:21:18 +0000
Subject: [issue2740] Cmd module doesn't support readline completion on OSX
	Leopard
In-Reply-To: <1209751540.52.0.644222816573.issue2740@psf.upfronthosting.co.za>
Message-ID: <1252243278.87.0.965421453104.issue2740@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As mentioned before I'm closing this as "won't fix" because this is an 
issue with Apple's copy of Python, not the one shipped by us (the generic 
Python tree doesn't even compile correctly when using libedit)

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Sep  6 15:25:04 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 13:25:04 +0000
Subject: [issue1738250] Universal MacPython 2.5.1 installation fails
Message-ID: <1252243504.79.0.764716315724.issue1738250@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing this bug as it is for an old version of Python and I cannot 
reproduce this issue.

----------
resolution:  -> works for me
status: open -> closed
versions: +Python 2.5

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

From report at bugs.python.org  Sun Sep  6 15:28:48 2009
From: report at bugs.python.org (Joshua Root)
Date: Sun, 06 Sep 2009 13:28:48 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252243728.75.0.743226127155.issue6802@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

It works now. Thanks!

----------

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

From report at bugs.python.org  Sun Sep  6 15:31:51 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 13:31:51 +0000
Subject: [issue2276] distutils out-of-date for runtime_library_dirs flag on OS
	X
In-Reply-To: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za>
Message-ID: <1252243911.5.0.698493443387.issue2276@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Could you provide an example that shows why adding support for the -rpath 
option on OSX would be useful? (As in a set of source files that shows how 
this support would be used).

As I mentioned before the OSX support for -rpath behaves completely 
different than that on Linux, and I'd expect that adding 
runline_library_dirs_option support for OSX would cause confusion because 
of that.

----------

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

From report at bugs.python.org  Sun Sep  6 15:36:33 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 13:36:33 +0000
Subject: [issue1467201] size_t warnings on OSX 10.3
Message-ID: <1252244193.27.0.566244935159.issue1467201@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The warning does not occur on recent versions of OSX (10.5, 10.6), 
therefore closing the issue.

----------
nosy: +ronaldoussoren
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sun Sep  6 15:38:29 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 13:38:29 +0000
Subject: [issue734115] Packaging without disturbing an existing installation
Message-ID: <1252244309.56.0.155162750115.issue734115@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing this issue, the patch is no longer needed because the current 
Makefiles already have DESTDIR support.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Sep  6 16:02:37 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 14:02:37 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1252245757.66.0.69789170805.issue6393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied the fixed version of my patch in r74687 (3.x) and r74688 
(3.1).

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

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

From report at bugs.python.org  Sun Sep  6 16:19:03 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 14:19:03 +0000
Subject: [issue1445781] install fails on hard link
Message-ID: <1252246743.94.0.142872217566.issue1445781@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy:  -ronaldoussoren

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

From report at bugs.python.org  Sun Sep  6 16:30:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 14:30:30 +0000
Subject: [issue1502517] crash in expat when compiling with --enable-profiling
Message-ID: <1252247430.32.0.210823448186.issue1502517@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is no longer a problem with 2.6.x from SVN and Xcode 3.2 (on OSX 
10.6). I haven't tested if the problem is still present on other versions 
of OSX, but I'd say it is pretty safe to assume that this was a toolchain 
problem.

----------

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

From report at bugs.python.org  Sun Sep  6 16:31:21 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 14:31:21 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <1252247481.21.0.0416094579244.issue1677@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy:  -ronaldoussoren

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

From report at bugs.python.org  Sun Sep  6 19:21:47 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 06 Sep 2009 17:21:47 +0000
Subject: [issue6849] Tutorial changes
In-Reply-To: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
Message-ID: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>


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

There are a couple of minor changes I'd like to make to the tutorial. 

Section 6.1 introduces the import * syntax without noting that it is bad
practise. I'd like to add the following text:

The import * form is generally considered to be bad practise as it makes
it hard to tell where the names you use in your code come from, *and*
you can accidentally overwrite names if you import something that is
already defined elsewhere. It can still be useful when working in the
console.


Section 6.4.1 uses Windows 95 and DOS 8+3 as the reason that importing
from packages doesn't automatically import all sub-packages. This is out
of date and not the most compelling reasoning anyway. I'd like to
replace that text with:


Perhaps this should go out to the filesystem, find which submodules are
present in the package, and import them all. This could take a long time
and importing sub-modules might have unwanted side-effects that should
only happen when the sub-module is explicitly imported.

----------
assignee: michael.foord
components: Documentation
keywords: easy
messages: 92324
nosy: michael.foord
severity: normal
status: open
title: Tutorial changes
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Sep  6 20:56:28 2009
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 06 Sep 2009 18:56:28 +0000
Subject: [issue1739648] zipfile.testzip() using progressive file reads
Message-ID: <1252263388.39.0.940591249177.issue1739648@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Attached is a patch that makes the zipfile module check the result of
testzip when run as __main__ as well as in test_zipfile.py, and adds
some tests in test_zipfile64.py.  The changes to test_zipfile64.py
increased its runtime from ~671 sec to ~1060 sec on my machine; I'm not
sure if that's too much.

----------
Added file: http://bugs.python.org/file14847/testzip-patch2.diff

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

From report at bugs.python.org  Sun Sep  6 20:58:42 2009
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 06 Sep 2009 18:58:42 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252263522.82.0.5885418213.issue6839@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

FileRoller doesn't complain about the mismatched slashes either.  Where
did the ZIP come from, by the way?  I seem to recall that there have
been other instances in which ZIP applications were more "forgiving"
than the zipfile module.  How far should zipfile go in bending the
interpretation of the ZIP standard?  

As far as the renaming goes, it seems the standard says the header name
should be used if the two names are different.  If nobody else has time
to make a patch and tests I can take a stab at it in the next few days.

----------
nosy: +alanmcintyre

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

From report at bugs.python.org  Sun Sep  6 21:51:04 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 06 Sep 2009 19:51:04 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252266664.53.0.404600086304.issue6836@psf.upfronthosting.co.za>


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

Good point, Tim.  I'll rework it so that one of the border bytes is 
used, since it needs to be a "known" value anyway.  That should make 
things less messy.
Although resoning about the breakpoint is probably incorrect since you 
would put the breakpoint on the "serialno" global variable, and not on 
the location in each memory block.
Meanwhile, does anyone have anything to say about my suggested bugfix?  
I'm not familiar enough with the parser to know if there may be a 
performance penaltly in copying the string here, or whether we ought to 
try to widen the use of the PyObject_ api to skirt the issue.

----------

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

From report at bugs.python.org  Sun Sep  6 22:08:38 2009
From: report at bugs.python.org (Marcin Stepnicki)
Date: Sun, 06 Sep 2009 20:08:38 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1252267718.91.0.525964409028.issue1975@psf.upfronthosting.co.za>


Marcin Stepnicki <marcin.stepnicki at haibane.pl> added the comment:

I have just got bitten by this bug - I usually run my software under
Linux/Windows, this was the first time that my customer requested
specifically FreeBSD platform and I was *really* surprised. Not to
mention the fact that bug in Python came as the last thing to my mind -
I was blaming my code of course :-).

Anyway, I can confirm the patch works for me and I'd like to see it
included in future versions. Can I do something to make it happen? 

Regards,
Marcin

----------
nosy: +mstepnicki

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

From report at bugs.python.org  Sun Sep  6 22:20:40 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Sep 2009 20:20:40 +0000
Subject: [issue6848] curses module build failure (ncurses 5.7)
In-Reply-To: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>
Message-ID: <1252268440.13.0.623818407247.issue6848@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Sun Sep  6 22:35:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 20:35:16 +0000
Subject: [issue6848] curses module build failure (ncurses 5.7)
In-Reply-To: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>
Message-ID: <1252269316.83.0.0016180380157.issue6848@psf.upfronthosting.co.za>


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

I asked on the ncurses-bugs mailing list about this problem, and got an 
immediate and helpful reply from the ncurses maintainer (Thomas Dickey).

It turns out that this *is* a Mac-specific problem: in Snow Leopard the 
Apple-supplied ncurses.h defines NCURSES_OPAQUE to 1 (if it isn't already 
defined) by default, while a standard ncurses install defines 
NCURSES_OPAQUE to be 0 by default.  Furthermore, Thomas Dickey has said 
that he'll add an is_pad function for later use, so if the WINDOW flags do 
disappear or move in a future version of ncurses then there should be an 
easy workaround available at that time.

So just #defining NCURSES_OPAQUE to 0 for OS X >= 10.6 seems a reasonable 
way to fix this for now.

----------

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

From report at bugs.python.org  Sun Sep  6 22:41:56 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 20:41:56 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252269716.84.0.818918819662.issue6839@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

alan: I don't quite understand which filename you want to use when the 
name in the per-file header and the central directory don't match. 

Where in the standard is this prescribed? I couldn't find anything in 
the PKWare zipfile appnote [1]

My preference would be to use the central directory as the canonical 
value because scanning the entire zipfile to read the per-file header 
would give a significant overhead. This might not be very noticable with 
small zipfiles, but I regularly use zipfiles with over 100K files in 
them in those files a scan of the zipfile is prohibitively expensive.

Furthermore, when the two are different the most reasonably explaination 
is that an in-place edit of the zipfile changed the directory without 
rewriting the entire zipfile (just like you can "delete" files from a 
zipfile by dumping them from the directory rather than completely 
rewriting the entire archive)

[1] 
APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.2 
Revised: September 28, 2007 
Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved.

----------

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

From report at bugs.python.org  Sun Sep  6 22:47:04 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Sep 2009 20:47:04 +0000
Subject: [issue6848] curses module build failure (ncurses 5.7)
In-Reply-To: <1252269316.83.0.0016180380157.issue6848@psf.upfronthosting.co.za>
Message-ID: <bbaeab100909061346n7fcba980ic611cc5d64c79b84@mail.gmail.com>


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

On Sun, Sep 6, 2009 at 13:35, Mark Dickinson<report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> I asked on the ncurses-bugs mailing list about this problem, and got an
> immediate and helpful reply from the ncurses maintainer (Thomas Dickey).
>
> It turns out that this *is* a Mac-specific problem: in Snow Leopard the
> Apple-supplied ncurses.h defines NCURSES_OPAQUE to 1 (if it isn't already
> defined) by default, while a standard ncurses install defines
> NCURSES_OPAQUE to be 0 by default. ?Furthermore, Thomas Dickey has said
> that he'll add an is_pad function for later use, so if the WINDOW flags do
> disappear or move in a future version of ncurses then there should be an
> easy workaround available at that time.
>
> So just #defining NCURSES_OPAQUE to 0 for OS X >= 10.6 seems a reasonable
> way to fix this for now.

Seems reasonable to me as well.

----------

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

From report at bugs.python.org  Sun Sep  6 22:58:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 20:58:45 +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: <1252270725.67.0.954879794883.issue6075@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patches look acceptable on first glance.

Which configurations of Tk have you tested? IMHO IDLE should work with the 
following configurations:

* Tk.framework as supplied with OSX 10.4, 10.5 and 10.6

* The current releases of Tk 8.4 and 8.5 installed in /Library/Frameworks

* Tk-Cocoa

----------

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

From report at bugs.python.org  Sun Sep  6 23:03:37 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 21:03:37 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1252271017.01.0.0521065876125.issue6441@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The (untested) attached patch ("setup-tk-archs.patch") updates the code in 
setup.py to automaticly detect the architectures that are supported by the 
Tk framework and passes '-arch' flags to the compiler for the intersection 
of the configured architectures for Python and the architectures supported 
by Tk.framework.

----------
keywords: +patch
Added file: http://bugs.python.org/file14848/setup-tk-archs.patch

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

From report at bugs.python.org  Sun Sep  6 23:13:19 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sun, 06 Sep 2009 21:13:19 +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: <1252271599.61.0.231800891065.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Tested against Tk-Cocoa (the build of Tk-8.5 that comes with Snow Leopard; 
I also have my own build on Leopard) and Tk-Carbon 8.5 on Leopard/10.5, 
and it works as expected. I no longer have any builds of 8.4 to test 
against. The code defaults to the current behavior of Tk-Carbon if a Cocoa 
build is not detected.

----------

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

From report at bugs.python.org  Sun Sep  6 23:20:55 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Sep 2009 21:20:55 +0000
Subject: [issue1584] Mac OS X: building with X11 Tkinter
In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>
Message-ID: <1252272055.02.0.797916111067.issue1584@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


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

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

From report at bugs.python.org  Sun Sep  6 23:26:52 2009
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 06 Sep 2009 21:26:52 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252272412.33.0.510923135582.issue6839@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Sorry about the confusion--I think I confused myself by looking at the
bit about CRC checksums in the "Info-ZIP Unicode Path Extra Field"
section before I posted.  I meant to say that the central directory name
looks preferred over the per-file header.

n section J, under "file name (Variable)" there's a bit that says:

"If input came from standard input, there is no file name field.  If
encrypting the central directory and general purpose bit flag 13 is set
indicating masking, the file name stored in the Local Header will not be
the actual file name.  A masking value consisting of a unique
hexadecimal value will be stored."

So in these cases the central directory name has to be used.  And, as
you pointed out, some operations like "deleting" a member from the
archive are implemented by editing the central directory, so it would
seem that the central directory should be used if there's a conflict.

----------

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

From report at bugs.python.org  Sun Sep  6 23:28:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 21:28:35 +0000
Subject: [issue6848] curses module build failure (ncurses 5.7)
In-Reply-To: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>
Message-ID: <1252272515.69.0.821982469501.issue6848@psf.upfronthosting.co.za>


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

Fixed in r74693, r74694, r74696, r74697.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Sep  6 23:34:28 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 06 Sep 2009 21:34:28 +0000
Subject: [issue6850] decimal.py: format_dict['type'] not initialized
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

it looks like format_dict['type'] is not always initialized:

>>> from decimal import *
>>> format(Decimal("0.12345"), "a=-7.0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/decimal.py", line 3611, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.1/decimal.py", line 5595, in
_parse_format_specifier
    if format_dict['type'] in 'gG' or format_dict['type'] is None:
TypeError: 'in <string>' requires string as left operand, not NoneType


Inserting these two lines somewhere in _parse_format_specifier fixes the
problem. (float() uses 'g' as the default, but I got the impression that
decimal.py uses uppercase as the default.) 

if format_dict['type'] is None:
    format_dict['type'] = 'G'

----------
messages: 92337
nosy: skrah
severity: normal
status: open
title: decimal.py: format_dict['type'] not initialized
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Sep  6 23:54:39 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 06 Sep 2009 21:54:39 +0000
Subject: [issue6849] Tutorial changes
In-Reply-To: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
Message-ID: <1252274079.28.0.800301174416.issue6849@psf.upfronthosting.co.za>


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

In addition section 8.3 of the tutorial references the .message
attribute which is now deprecated.

But use of .args is discouraged. Instead, the preferred use is to pass a
single argument to an exception (which can be a tuple if multiple
arguments are needed) and have it bound to the message attribute. One
may also instantiate an exception first before raising it and add any
attributes to it as desired.

----------

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

From report at bugs.python.org  Mon Sep  7 00:00:16 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 06 Sep 2009 22:00:16 +0000
Subject: [issue6849] Tutorial changes
In-Reply-To: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
Message-ID: <1252274416.85.0.601547215371.issue6849@psf.upfronthosting.co.za>


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

The TransitionError defined in section 8.5 of the tutorial has a
'message' argument / attribute that will raise a DeprecationWarning in
Python 2.6.

----------

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

From report at bugs.python.org  Mon Sep  7 00:28:21 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Sun, 06 Sep 2009 22:28:21 +0000
Subject: [issue6845] ftplib rest support for storbinary
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1252276101.86.0.976477477082.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


----------
nosy: +facundobatista

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

From report at bugs.python.org  Mon Sep  7 01:13:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Sep 2009 23:13:22 +0000
Subject: [issue6850] decimal.py: format_dict['type'] not initialized
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252278802.16.0.341258425059.issue6850@psf.upfronthosting.co.za>


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


----------
assignee:  -> marketdickinson
nosy: +marketdickinson

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

From report at bugs.python.org  Mon Sep  7 02:00:59 2009
From: report at bugs.python.org (jweber)
Date: Mon, 07 Sep 2009 00:00:59 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>


New submission from jweber <jacob at jacobweber.com>:

The following program works fine under Mac OS 10.5.x. But in 10.6, it 
crashes Python, and displays Apple's crash reporter dialog. I've tried 
it on Python 2.6 and 2.5, both the 64-bit and 32-bit versions.

The crash seems to happen any time urllib.urlopen is done in a thread. 
The same thing happens if I do it in a BaseHTTPServer.HTTPServer, using 
SocketServer.ThreadingMixIn.


#!/usr/bin/python
import threading, urllib

class MyThread (threading.Thread):
	def run(self):
		c = urllib.urlopen("http://www.google.com")

MyThread().start()

----------
assignee: ronaldoussoren
components: Macintosh
files: crash_log.txt
messages: 92340
nosy: jweber, ronaldoussoren
severity: normal
status: open
title: urllib.urlopen crashes in a thread on Snow Leopard
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14849/crash_log.txt

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

From report at bugs.python.org  Mon Sep  7 06:32:21 2009
From: report at bugs.python.org (loveminix)
Date: Mon, 07 Sep 2009 04:32:21 +0000
Subject: [issue6852] Unicode IO not working in cgi applet
In-Reply-To: <1252297939.29.0.310972528107.issue6852@psf.upfronthosting.co.za>
Message-ID: <1252297939.29.0.310972528107.issue6852@psf.upfronthosting.co.za>


New submission from loveminix <loveminix at yahoo.com.cn>:

The following cgi applet does output Unicode string correctly in an
Ubuntu terminal, but when invoked from a web browser (IE or Firefox) by
a client, it doesn't output the Unicode string. Output stops at
"...<div><p>", right before the Unicode string "??".

#! /usr/bin/python3
# -*- coding: utf-8 -*-

print(
"""\
Content-type: text/html
"""
);

print(
"""\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head>
<body>\
"""
);

print("<div><p>");
print("??");
print("</p></div>");

print(
"""\
</body>
</html>\
"""
);

----------
components: Unicode
messages: 92341
nosy: loveminix
severity: normal
status: open
title: Unicode IO not working in cgi applet
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Sep  7 06:46:44 2009
From: report at bugs.python.org (lplatypus)
Date: Mon, 07 Sep 2009 04:46:44 +0000
Subject: [issue6853] system proxy not used for https (on windows)
In-Reply-To: <1252298794.29.0.673935576663.issue6853@psf.upfronthosting.co.za>
Message-ID: <1252298794.29.0.673935576663.issue6853@psf.upfronthosting.co.za>


New submission from lplatypus <luke at deller.id.au>:

On Windows, the urllib2 module (renamed to urllib.request in python 3)
does not use the system web proxy for https URLs in the case where "Use
the same proxy for all protocols" is selected in the Internet Explorer
proxy settings.

Attached is a patch against urllib/request.py in python 3.1.1

----------
components: Library (Lib)
files: urllib-httpsproxy.patch
keywords: patch
messages: 92342
nosy: ldeller
severity: normal
status: open
title: system proxy not used for https (on windows)
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14850/urllib-httpsproxy.patch

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

From report at bugs.python.org  Mon Sep  7 07:13:35 2009
From: report at bugs.python.org (loveminix)
Date: Mon, 07 Sep 2009 05:13:35 +0000
Subject: [issue6854] UnicodeDecodeError when retrieving binary data from
	cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>


New submission from loveminix <loveminix at yahoo.com.cn>:

The following cgi applet uploads a binary file to the server. It gets a
"UnicodeDecodeError" inside cgi.FieldStorage(). The same code works in
python 2.6.

#! /usr/bin/python3

import os, cgi;
import cgitb; cgitb.enable();

pathInfo = os.environ.get("PATH_INFO", "");
serverName = os.environ.get("SERVER_NAME", "");
scriptName = os.environ.get("SCRIPT_NAME", "");

if pathInfo == "":
    print(
"""\
Content-type: text/html
"""
);
    print(
"""\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
    <meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head>
<body>
    <div>
        <form action="http://{0}{1}/upload"
enctype="multipart/form-data" method="post">
        <p>
            <input type="file" name="file"><br>
            <input type="submit" value="Upload">
        </p>
        </form>
    </div>
</body>
</html>\
""".format(serverName, scriptName)
);
elif pathInfo == "/upload":
    fieldStorage = cgi.FieldStorage();
    fileItem = fieldStorage["file"];
    if fileItem.filename != "":
        file = open("/tmp/test.txt", mode="wb");
        file.write(fileItem.file.read());
        file.close();
        print(
"""\
Content-type: text/html
"""
);
        print(
"""\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
    <meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head>
<body>
    <div>
        <p>Success</p>
    </div>
</body>
</html>\
"""
);

----------
components: Library (Lib)
messages: 92343
nosy: loveminix
severity: normal
status: open
title: UnicodeDecodeError when retrieving binary data from cgi.FieldStorage()
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Sep  7 07:56:44 2009
From: report at bugs.python.org (Bryan Blackburn)
Date: Mon, 07 Sep 2009 05:56:44 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1252303004.77.0.589492130449.issue6802@psf.upfronthosting.co.za>


Bryan Blackburn <blb at users.sourceforge.net> added the comment:

The patch has one issue in the added AC_TRY_RUN ( 
http://svn.python.org/view/python/trunk/configure.in?
annotate=74672&pathrev=74672#l1542 ): it doesn't like the two [[...]] and 
main() needs a closing brace, }.  Otherwise, it fails on 10.5.8 (Xcode 
3.1.3, Intel) to properly detect 32bit vs 64bit (and if you look at 
config.log you should see complaints from around line 7065).

Attaching a patch which fixes it here.

----------
Added file: http://bugs.python.org/file14851/configure.in.diff

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

From report at bugs.python.org  Mon Sep  7 08:29:47 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 07 Sep 2009 06:29:47 +0000
Subject: [issue6855] ihooks support for relative imports
In-Reply-To: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za>
Message-ID: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

ihooks in 2.6 does not support relative imports. The attached patch was 
impired by Brett's "import in Python" code.

----------
assignee: brett.cannon
components: Library (Lib)
files: ihooks_relimport.txt
messages: 92345
nosy: brett.cannon, nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: ihooks support for relative imports
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14852/ihooks_relimport.txt

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

From report at bugs.python.org  Mon Sep  7 09:41:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 07:41:11 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1252309271.11.0.849790483006.issue6516@psf.upfronthosting.co.za>


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

We can add two options to the commands that create tarballs:

- owner
- group
 

but we first need to add this capacity to the tarfile module because
right now the API doesn't allow you to add files with custom uid and gid.

I am going to add another issue with a proposal for this.

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

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

From report at bugs.python.org  Mon Sep  7 09:41:24 2009
From: report at bugs.python.org (Ravon Jean-Michel)
Date: Mon, 07 Sep 2009 07:41:24 +0000
Subject: [issue1457] Cannot write an array in a file opened in r+b mode.
In-Reply-To: <1252081471.59.0.215779888379.issue1457@psf.upfronthosting.co.za>
Message-ID: <A8DD7B2ABEB7B842AF607D392FF73C7EBA08EA07FC@CROEXCFWP03.gemalto.com>


Ravon Jean-Michel <Jean-Michel.Ravon at gemalto.com> added the comment:

It works in python 2.5. Why not in jython?

----------
nosy: +jmravon
title: IDLE - configDialog - new layout for key config -> Cannot write an array in a file opened in r+b mode.

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

From report at bugs.python.org  Mon Sep  7 09:47:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 07:47:30 +0000
Subject: [issue6856] allow settong uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>


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

I am proposing this feature for an issue we have in Distutils: being
able to set the uid/gid of files added in a tar archive using tarfile.

Here's what I am proposing:

- adding two methods to TarInfo: set_uid and set_gid, that are able to
take a user and group name *or* a uid and gid number

- adding in TarFile a new filter option to add() called include. If
given, it's a callable that receives the tarinfo object right before
it's added, so its uid/gid can be tweaked. This callable must return the
object. If it returns None, the object is not added to the tar file.

----------
components: Library (Lib)
messages: 92348
nosy: lars.gustaebel, tarek
severity: normal
status: open
title: allow settong uid and gid when creating tar files
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Sep  7 09:48:08 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 07:48:08 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1252309688.29.0.511998704775.issue6516@psf.upfronthosting.co.za>


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

#6856 created.

----------
dependencies: +allow settong uid and gid when creating tar files

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

From report at bugs.python.org  Mon Sep  7 09:48:21 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 07:48:21 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252309701.11.0.267466528457.issue6856@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
title: allow settong uid and gid when creating tar files -> allow setting uid and gid when creating tar files

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

From report at bugs.python.org  Mon Sep  7 09:55:50 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 07:55:50 +0000
Subject: [issue6546] [Distutils][PATCH] Add bdist_rpm option to select the
	name of the resulting package
In-Reply-To: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>
Message-ID: <1252310150.37.0.0129274683654.issue6546@psf.upfronthosting.co.za>


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

Can you explain the reason why you need to change the distribution name,
and not use the name+version metadata to do it ?

Thanks

----------

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

From report at bugs.python.org  Mon Sep  7 10:00:19 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 08:00:19 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252310418.99.0.16007378711.issue6163@psf.upfronthosting.co.za>


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

Ok so, just to make sure, the final patch for both changes should be:

{{{
...
elif sys.platform[:5] == "hp-ux":
    if compiler.find('gcc'):
        return ["-Wl,+s", "-L" + dir]
    return ["+s", "-L" + dir]
...
}}}

----------

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

From report at bugs.python.org  Mon Sep  7 10:05:05 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 08:05:05 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1252310705.35.0.829852117151.issue6296@psf.upfronthosting.co.za>


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

I think there's no consensus at this point in the "best" format for all
platform.

I am closing this issue as "wontfix". Maybe a new format will rule them
all in a few years.
 
Michael, can you create a specific issue for the CRLF problem ? Thanks a
lot.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Sep  7 10:10:18 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 08:10:18 +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: <1252311018.59.0.662622470251.issue6145@psf.upfronthosting.co.za>


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

Thanks for the patch. 

I need to look at how read_setup_file is actually used in the community,
then apply the patch in consequence.

----------
type:  -> behavior
versions:  -Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Sep  7 10:11:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 08:11:24 +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: <1252311084.59.0.424385267824.issue6114@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Mon Sep  7 10:12:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 08:12:04 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1252311124.19.0.403104895033.issue6377@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> high

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

From report at bugs.python.org  Mon Sep  7 10:20:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Sep 2009 08:20:30 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252311630.18.0.0491818365636.issue6856@psf.upfronthosting.co.za>


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


----------
assignee:  -> lars.gustaebel

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

From report at bugs.python.org  Mon Sep  7 11:16:51 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Mon, 07 Sep 2009 09:16:51 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252315011.3.0.683886597254.issue6163@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

Basically yes, two minor ones:
*) also look for 'g++',
*) string.find() returns the index where found, -1 when not found,
so:
{{{
...
elif sys.platform[:5] == "hp-ux":
    if compiler.find('gcc') >= 0 or compiler.find('g++') >= 0:
        return ["-Wl,+s", "-L" + dir]
    return ["+s", "-L" + dir]
...
}}}

Two lines below already is another search for 'gcc' or 'g++', which also
should be changed from 'compiler[:3]' to 'compiler.find()':
{{{
...
elif compiler.find("gcc") >= 0 or compiler.find("g++") >= 0:
    return "-Wl,-R" + dir
...
}}}

Thank you!

----------

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

From report at bugs.python.org  Mon Sep  7 11:36:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 09:36:02 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252316162.06.0.57560224329.issue6163@psf.upfronthosting.co.za>


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

> Two lines below already is another search for 'gcc' or 'g++', 
> which also should be changed from 'compiler[:3]' to 'compiler.find()'

But compiler[:3] implies that the compiler string starts *with* 'gcc'.

so are you sure we're looking for 'gcc' anywhere in the string,
or at the beginning of it ?

In any case, I find these string searches very weak in there. I am going
to  refactor a function in distutils that guesses the type of compiler,
given a list of known compilers 'names' and a list of matching strings
(or regular expressions) for them.

I'll take all cases from unixcompiler and add a test for that, then use
it in this code.

Please don't hesitate to give me your list of

compiler string -> compiler 'type'

so I can add them in my test.

Thanks !

----------

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

From report at bugs.python.org  Mon Sep  7 11:59:18 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Sep 2009 09:59:18 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252317558.98.0.352626960068.issue6829@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

How about:

Error running metaclass bases
(attempt to inherit from object that is not a class)

----------

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

From report at bugs.python.org  Mon Sep  7 12:00:28 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Sep 2009 10:00:28 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252317628.67.0.962408985599.issue6829@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Or just:

Error inheriting from object that is not a class

----------

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

From report at bugs.python.org  Mon Sep  7 12:02:08 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Sep 2009 10:02:08 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252317728.0.0.425624836224.issue6829@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Or with more info if possible:

Error when inheriting class "%s" - parent is not a class.

----------

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

From report at bugs.python.org  Mon Sep  7 13:07:12 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Mon, 07 Sep 2009 11:07:12 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252321632.02.0.208595498395.issue6163@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

> But compiler[:3] implies that the compiler string starts *with* 'gcc'.
> 
> so are you sure we're looking for 'gcc' anywhere in the string,
> or at the beginning of it ?

It is very common to use the host triplet in the compiler name, like
'i686-pc-linux-gnu-gcc', even for non-cross builds. Sometimes the
compiler string also looks like 'ccache gcc' or 'distcc gcc'. Even
'/path/to/some/gcc' is possible, in combination with '/path/to/ccache'
and/or '/path/to/distcc'. And sometimes the version number is appended,
like 'gcc-X.Y.Z'. Also ABI-specific flags might be set there, like 'gcc
-m32'.

> In any case, I find these string searches very weak in there.

Agreed, but AFAICT, native and other non-gcc compilers never do have
something like 'gcc' in their installation path, especially not in their
executable basename (on AIX, HP-UX, Solaris). So eventually it is save
enough to search for gcc/g++ after the last path-separator, although
this won't work for things like 'gcc -I/my/local/include'.

> I am going to refactor a function in distutils that guesses the type
> of compiler, given a list of known compilers 'names' and a list of
> matching strings (or regular expressions) for them.

The most reliable way IMHO would be to preprocess '#ifdef __GNUC__', and
avoid searching the compiler string for anything.

Thank you!

----------

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

From report at bugs.python.org  Mon Sep  7 13:51:55 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Sep 2009 11:51:55 +0000
Subject: [issue6854] UnicodeDecodeError when retrieving binary data from
	cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1252324315.15.0.49796136506.issue6854@psf.upfronthosting.co.za>


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

Can you paste the traceback of the error?

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

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

From report at bugs.python.org  Mon Sep  7 13:52:25 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 07 Sep 2009 11:52:25 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252324345.72.0.751381824045.issue6856@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

TarInfo does not need set_uid() or set_gid() methods, both can be set
using the uid and gid attributes.
If the list of files to add to the archive is known you can do this:

tar = tarfile.open("foo.tar.gz", "w:gz")
for filename in filenames:
  tarinfo = tar.gettarinfo(filename)
  if tarinfo.isreg():
    fobj = open(filename)
  else:
    fobj = None
  tarinfo.uid = 0
  tarinfo.gid = 0
  tar.addfile(tarinfo, fobj)
tar.close()

I am not against adding a new option. Although, it's too bad that I
added the exclude option in 2.6 not long ago, which does something very
similar and would again be replaced by this more general "include"
option. BTW, I think calling the option "filter" would be more suitable
for what it's doing.

----------

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

From report at bugs.python.org  Mon Sep  7 13:57:07 2009
From: report at bugs.python.org (Duncan Grisby)
Date: Mon, 07 Sep 2009 11:57:07 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252324627.82.0.743096878075.issue6844@psf.upfronthosting.co.za>


Duncan Grisby <duncan-python at grisby.org> added the comment:

This affects my application too. We have a large body of code that uses
exception classes automatically generated from CORBA IDL, with
attributes named "message". It is infeasible for us to change to use a
different attribute name. We've ended up with dirty hacks all over the
place to suppress the warnings.

----------
nosy: +dgrisby

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

From report at bugs.python.org  Mon Sep  7 14:25:25 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 12:25:25 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252326325.22.0.233890252726.issue6856@psf.upfronthosting.co.za>


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

> TarInfo does not need set_uid() or set_gid() methods, 
> both can be set using the uid and gid attributes.

I was thinking about the set_ methods to be able to use
"root" (str) instead of "0" (int) for example, like 
what the tar command seems to allow with --uid and --gid.


> I am not against adding a new option. Although, it's too bad that 
> I added the exclude option in 2.6 not long ago, which does 
> something very similar and would again be replaced by this 
> more general "include" option. BTW, I think calling 
> the option "filter" would be more suitable for what it's doing.

Maybe we could add the "filter" option for 2.7/3.2 together with the
exclude option? And add a deprecation warning for "exclude" when it's
used, since it would then become *one* use case for "filter".

We could also add an exclude callable in the module, as an example
usage of the filter option, exactly like I did for shutil.copytree
(look for ignore_patterns).

----------

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

From report at bugs.python.org  Mon Sep  7 14:38:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Sep 2009 12:38:48 +0000
Subject: [issue1457] IDLE - configDialog - new layout for key config
In-Reply-To: <1195399530.13.0.0197942557234.issue1457@psf.upfronthosting.co.za>
Message-ID: <1252327128.14.0.627569456185.issue1457@psf.upfronthosting.co.za>


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

I suppose this update should have been directed to bugs.jython.org.
Something is probably wrong with the jython issue tracker...

----------
nosy: +amaury.forgeotdarc, loewis
title: Cannot write an array in a file opened in r+b mode. -> IDLE - configDialog - new layout for key config

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

From report at bugs.python.org  Mon Sep  7 15:26:44 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Sep 2009 13:26:44 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252330004.55.0.0963363329553.issue6713@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/issue6713>
_______________________________________

From report at bugs.python.org  Mon Sep  7 15:37:32 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Sep 2009 13:37:32 +0000
Subject: [issue6850] decimal.py: format_dict['type'] not initialized
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252330652.22.0.38710941148.issue6850@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/issue6850>
_______________________________________

From report at bugs.python.org  Mon Sep  7 15:42:16 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Sep 2009 13:42:16 +0000
Subject: [issue6850] decimal.py: format_dict['type'] not initialized
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252330936.43.0.253303390161.issue6850@psf.upfronthosting.co.za>


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

The test as written will always give an error for None. I think the
better fix is to change it to be:

if format_dict['type'] is None or format_dict['type'] in 'gG':

That "fixes" this particular exception, but since the format specifier
is invalid, it produces nonsense. I think Decimal's format parser needs
to detect this as an error.

----------

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

From report at bugs.python.org  Mon Sep  7 15:44:39 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Sep 2009 13:44:39 +0000
Subject: [issue6850] decimal.py: format_dict['type'] not initialized
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252331079.35.0.364730898051.issue6850@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
components: +Library (Lib)
type:  -> behavior

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

From report at bugs.python.org  Mon Sep  7 16:32:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Sep 2009 14:32:13 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1252333933.23.0.0688081255163.issue6829@psf.upfronthosting.co.za>


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

It is possible that a TypeError could arise during the execution of the
metaclass bases that is not the result of inheriting from something
other than a class/type.  It might, however, be possible to enhnace the
message with the name of the metaclass or first base class...but someone
who knows more about the interpreter internals than I do would have to
be willing to take that on, as it isn't clear to me from reading the
code what the right thing would be to put in the message.

----------

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

From report at bugs.python.org  Mon Sep  7 17:21:07 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Sep 2009 15:21:07 +0000
Subject: [issue6850] decimal.py: format_dict
In-Reply-To: <1252330936.43.0.253303390161.issue6850@psf.upfronthosting.co.za>
Message-ID: <20090907172035.GA3983@mail.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Eric Smith <report at bugs.python.org> wrote:
> The test as written will always give an error for None. I think the
> better fix is to change it to be:
> 
> if format_dict['type'] is None or format_dict['type'] in 'gG':
> 
> That "fixes" this particular exception, but since the format specifier
> is invalid, it produces nonsense. I think Decimal's format parser needs
> to detect this as an error.

Do you mean that zero significant digits are invalid or that the conversion
specifier cannot be omitted? If I look at the following, the intentions are
not quite clear to me:

'0.1    '

'0.1    '

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/decimal.py", line 3611, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.1/decimal.py", line 5595, in _parse_format_specifier
    if format_dict['type'] in 'gG' or format_dict['type'] is None:
TypeError: 'in <string>' requires string as left operand, not NoneType

'    0.1'

1. Conversion specifier can be omitted if significant digits != 0.

2. Significant digits can be zero if conversion specifier is present.

3. Exception

4. float() accepts the format.

I would be in favour of making the conversion specifier mandatory - and
perhaps disallow zero significant digits in the case of 'g'.  If the
intention is to mimic the C Standard, zero significant digits should
probably be silently promoted to one.

In any case, float() and Decimal() should preferably behave identically.

P.S.:

Unrelated, but I just see that float() has the wrong default alignment.

----------
title: decimal.py: format_dict['type'] not initialized -> decimal.py: format_dict

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

From report at bugs.python.org  Mon Sep  7 17:27:58 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Sep 2009 15:27:58 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251469621.38.0.248001245965.issue6795@psf.upfronthosting.co.za>
Message-ID: <20090907172735.GA4483@mail.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[...]
> But in Python this error condition *can* 'otherwise be indicated', by 
> raising a suitable Python exception.  So I propose changing the decimal 
> module in 2.7 and 3.2 so that int(Decimal('nan')) and 
> long(Decimal('nan')) raise ValueError.

Excellent analysis, I would be very much in favour of this.

> Issue 3. I can't see how this could cause any real problems, since you'd 
> get an error as soon as you tried to use a bogus context.  Further, an 
> explicit typecheck goes against Python's duck-typing philosophy:  a 
> suitably crazy and misguided person ought to be able to create their own 
> 'quacks like a context' class, not necessarily inheriting from 
> Decimal.Context, and pass this into setcontext in place of a real 
> context.  I'm -0 on changing this.

Agreed, it's not really important.

----------

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

From report at bugs.python.org  Mon Sep  7 17:31:40 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Sep 2009 15:31:40 +0000
Subject: [issue6850] decimal.py: format_dict
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252337500.71.0.782566612854.issue6850@psf.upfronthosting.co.za>


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

The format string is valid. Sorry for the noise. The fill character of
'a' threw me off.

With my suggested change to decimal.py, line 5595, in py3k:
>>> from decimal import *
>>> format(Decimal("0.12345"), "a=-7.0")
'aaaa0.1'
>>> format(0.12345, "a=-7.0")
'aaaa0.1'
>>> 

If float has the wrong alignment, could you open another issue with an
example?

----------

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

From report at bugs.python.org  Mon Sep  7 17:46:48 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Sep 2009 15:46:48 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

format(float("0.12345"), "7.0")  ->  '    0.1'

The default alignment should be 'left-aligned'.

----------
messages: 92370
nosy: skrah
severity: normal
status: open
title: float().__format__() default alignment
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Sep  7 17:48:00 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Sep 2009 15:48:00 +0000
Subject: [issue6850] decimal.py: format_dict
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252338480.95.0.455771369366.issue6850@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, I'll do that.  -  The tracker has eaten my examples, so hopefully
this goes through:

1. format(Decimal("0.12345"), "7.1")   ->  '0.1    '

2. format(Decimal("0.12345"), "7.0g")  ->  '0.1    '

3. format(Decimal("0.12345"), "7.0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/decimal.py", line 3611, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.1/decimal.py", line 5595, in
_parse_format_specifier
    if format_dict['type'] in 'gG' or format_dict['type'] is None:
TypeError: 'in <string>' requires string as left operand, not NoneType

4. format(float("0.12345"), "7.0")     -> '    0.1'


But I've opened a separate issue now.

----------

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

From report at bugs.python.org  Mon Sep  7 17:49:48 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Sep 2009 15:49:48 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252338588.48.0.445802684768.issue6857@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


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

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

From report at bugs.python.org  Mon Sep  7 18:23:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Sep 2009 16:23:35 +0000
Subject: [issue6850] decimal.py: format_dict
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252340615.31.0.6713381906.issue6850@psf.upfronthosting.co.za>


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

Thanks for the report.  I've fixed the order of the checks as Eric 
suggested in r74704 (trunk), r74705 (release26-maint), r74706 (py3k) and 
r74707 (release31-maint).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Mon Sep  7 18:25:44 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 07 Sep 2009 16:25:44 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252340744.56.0.594418086004.issue6856@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I do not quite see the benefit from the set_* methods. Although the
attribute access I proposed may be slightly more complicated (because
you might need the pwd and grp modules) it offers the most freedom.
Let's take the set_uid() method as an example: Its purpose would be to
set both the uid and uname field in the tar header. That is fine as long
as its argument is a uid or username that actually exists. If set_uid()
gets a username that does not exist, what are we going to do? Only set
the uname field and leave the uid field alone or raise an exception? If
the user wants to set a non-existant username on purpose, he cannot use
the set_uid() method. And what are we going to do on Windows? Is there
anything comparable to pwd/grp we could use?
I expect the common use case for these both methods will be to *reset*
the owner information to a default, and this is done by setting uname to
"root" and uid to 0.

The filter argument is actually a nice idea. I have attached a patch
that outlines my idea of how it is supposed to be. Comments welcome.

----------
keywords: +patch
Added file: http://bugs.python.org/file14853/issue6856.diff

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

From report at bugs.python.org  Mon Sep  7 18:29:54 2009
From: report at bugs.python.org (Chris Frantz)
Date: Mon, 07 Sep 2009 16:29:54 +0000
Subject: [issue3597] Allow application developers to select ciphers,
	and default to strong in ssl lib
In-Reply-To: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
Message-ID: <1252340994.18.0.0103093021371.issue3597@psf.upfronthosting.co.za>


Chris Frantz <frantzcj at gmail.com> added the comment:

I believe the attached patch provides the desired functionality.

By default, the SSL library selects appropriate ciphers.  If the user
creates an SSLSocket with a cipher_list, the string is passed directly
to SSL_CTX_set_cipher_list().

----------
keywords: +patch
nosy: +cfrantz
Added file: http://bugs.python.org/file14854/py-ssl.diff

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

From report at bugs.python.org  Mon Sep  7 18:43:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 16:43:11 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252341791.6.0.21957960802.issue6856@psf.upfronthosting.co.za>


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

> I do not quite see the benefit from the set_* methods. 
> .. some explanations of the underlying complexity...

The only benefit I can see for the set_* method is to hide 
the underlying complexity you've explained.

In Distutils, I'd like to provide a uid and gid option
to the sdist command where the user can set "root" for instance
and see the lib taking care of creating a tarfile with everything
set to the right value (and ignore the flags under windows etc)

So it seems that working per TarInfo is the wrong approach, 
and a global function to create an archive would be better.


> The filter argument is actually a nice idea. I have attached a 
> patch that outlines my idea of how it is supposed to be. 
> Comments welcome.

The patch looks nice to me

small typo in the doc :

> How create

should be "How to create"

----------

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

From report at bugs.python.org  Mon Sep  7 18:44:16 2009
From: report at bugs.python.org (OG7)
Date: Mon, 07 Sep 2009 16:44:16 +0000
Subject: [issue6546] [Distutils][PATCH] Add bdist_rpm option to select the
	name of the resulting package
In-Reply-To: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>
Message-ID: <1252341856.82.0.187714903935.issue6546@psf.upfronthosting.co.za>


OG7 <onyxg7 at users.sourceforge.net> added the comment:

In most cases, a distribution named "foo" becomes and rpm named
"python-foo", so it can't be the same name for both.

I'm using bdist_rpm to generate rpms from eggs I didn't write myself, so
an option to give external control works best.

----------

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

From report at bugs.python.org  Mon Sep  7 19:37:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Sep 2009 17:37:21 +0000
Subject: [issue6831] 2to3 assignment division conversion
In-Reply-To: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>
Message-ID: <1252345041.99.0.56068007329.issue6831@psf.upfronthosting.co.za>


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

Could you expand a little on what you expect to happen, please?

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

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

From report at bugs.python.org  Mon Sep  7 19:42:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Sep 2009 17:42:46 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252345366.26.0.466629053066.issue6857@psf.upfronthosting.co.za>


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

Hmm.  PEP 3101 does indeed say that left-aligned is the default, but it's 
a bit of a strange default for numeric types.  I'd expect integers (at 
least) to be right-aligned by default.

I'd be inclined to say that the current float formatting is correct, and 
that it's the Decimal formatting that's wrong.

----------
nosy: +marketdickinson

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

From report at bugs.python.org  Mon Sep  7 19:52:42 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Sep 2009 17:52:42 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252345962.42.0.980340665793.issue6857@psf.upfronthosting.co.za>


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

That is interesting. I'd agree that it's a bug in the PEP. Note that
%-formatting right aligns floats by default:

>>> '%7.0g' % 0.12345
'    0.1'

I'll raise the issue on python-dev.

Eric.

----------
assignee:  -> eric.smith

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

From report at bugs.python.org  Mon Sep  7 20:09:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Sep 2009 18:09:55 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1252346995.58.0.705025985495.issue6795@psf.upfronthosting.co.za>


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

Fixed __long__ bug and changed behaviour of int(Decimal('nan')) in r74708 
(trunk), r74709 (py3k).  I still need to fix the __long__ bug in the 
release branches.

----------

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

From report at bugs.python.org  Mon Sep  7 20:12:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Sep 2009 18:12:31 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1252347151.33.0.869056620177.issue6795@psf.upfronthosting.co.za>


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

On second thoughts, I'm going to call this a bug and backport to 2.6 and 
3.1.

----------

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

From report at bugs.python.org  Mon Sep  7 20:26:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Sep 2009 18:26:55 +0000
Subject: [issue6852] Unicode IO not working in cgi applet
In-Reply-To: <1252297939.29.0.310972528107.issue6852@psf.upfronthosting.co.za>
Message-ID: <1252348015.35.0.480267866934.issue6852@psf.upfronthosting.co.za>


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

I don't think this is a Python bug;  it has to do with the stdout 
encoding.  When connected to a terminal, sys.stdout.encoding is 
(probably, on Ubuntu) UTF-8, but when you're using this as a cgi script 
it's likely to be defaulting to ascii instead.  Not surprisingly, Python 
won't let you send non-ASCII characters to a stream whose encoding is 
'ascii'.

A workaround is to use sys.stdout.buffer.write (which writes bytes, not 
text), and to manually encode your unicode output in whatever encoding 
you want ('utf-8', I'm assuming):

>>> sys.stdout.buffer.write('??\n'.encode('utf8'))
??
7

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

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

From report at bugs.python.org  Mon Sep  7 21:03:23 2009
From: report at bugs.python.org (Seamus O'Shea)
Date: Mon, 07 Sep 2009 19:03:23 +0000
Subject: [issue6812] Snow Leopard python program fails because
	_PyType_Modified is missing from python framework
In-Reply-To: <1252239013.92.0.217355282717.issue6812@psf.upfronthosting.co.za>
Message-ID: <73050266-C58C-444E-B7D1-8A29EF0E9204@uleth.ca>


Seamus O'Shea <oshea at uleth.ca> added the comment:

(1) When running python (/usr/bin/python) in Terminal I am able to  
import objc successfully. I printed the directory to be sure it's  
complete

Seamuss-MacBook:~ seamus$ /usr/bin/python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import objc
 >>> print dir(objc)
['Accessor', 'BadPrototypeError', 'CFToObject', 'Category', 'FSRef',  
'FSSpec', 'IBAction', 'IBOutlet', 'IMP', 'LockError',  
'MAC_OS_X_VERSION_10_1', ......

(2) I restarted Xcode, did a "Clean all" and rebuilt the app, but I  
got this dump

"Running???
2009-09-07 12:25:39.355 First_PyObjC[2796:a0f] mainFilePath is /Users/ 
seamus/Science/xcode exploration/Objc-programs/First_PyObjC/build/ 
Debug/First_PyObjC.app/Contents/Resources/main.py
2009-09-07 12:25:39.360 First_PyObjC[2796:a0f] pythonpath is (
     "/Users/seamus/Science/xcode exploration/Objc-programs/ 
First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources",
     "/Users/seamus/Science/xcode exploration/Objc-programs/ 
First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/PyObjC",
     "/System/Library/Frameworks/Python.framework/Versions/Current/ 
Extras/lib/python/"
)
Traceback (most recent call last):
   File "/Users/seamus/Science/xcode exploration/Objc-programs/ 
First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/main.py",  
line 10, in <module>
     import objc
   File "/System/Library/Frameworks/Python.framework/Versions/Current/ 
Extras/lib/python/PyObjC/objc/__init__.py", line 22, in <module>
     _update()
   File "/System/Library/Frameworks/Python.framework/Versions/Current/ 
Extras/lib/python/PyObjC/objc/__init__.py", line 19, in _update
     import _objc
ImportError: dlopen(/System/Library/Frameworks/Python.framework/ 
Versions/Current/Extras/lib/python/PyObjC/objc/_objc.so, 2): Symbol  
not found: _PyType_Modified
   Referenced from: /System/Library/Frameworks/Python.framework/ 
Versions/Current/Extras/lib/python/PyObjC/objc/_objc.so
   Expected in: flat namespace
  in /System/Library/Frameworks/Python.framework/Versions/Current/ 
Extras/lib/python/PyObjC/objc/_objc.so
2009-09-07 12:25:39.460 First_PyObjC[2796:a0f] *** Terminating app due  
to uncaught exception 'NSInternalInconsistencyException', reason: '/ 
Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/ 
main.m:46 main() PyRun_SimpleFile failed with file '/Users/seamus/ 
Science/xcode exploration/Objc-programs/First_PyObjC/build/Debug/ 
First_PyObjC.app/Contents/Resources/main.py'.  See console for errors.'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x90a1858a __raiseError + 410
	1   libobjc.A.dylib                     0x9309cf49  
objc_exception_throw + 56
	2   CoreFoundation                      0x90a182b8 +[NSException  
raise:format:arguments:] + 136
	3   CoreFoundation                      0x90a1822a +[NSException  
raise:format:] + 58
	4   First_PyObjC                        0x00002bc2 main + 1084
	5   First_PyObjC                        0x0000275a start + 54
)
sharedlibrary apply-load-rules all"

It seems identical to the original problem.

(3) I wondered if there is something the PATH specifications that  
caused things to be misdirected during the build, so I printed  
sys.path out from within python.

/Library/Python/2.6/site-packages/pyobjc-2.2b2-py2.6.egg
/Library/Python/2.6/site-packages/ 
pyobjc_framework_XgridFoundation-2.2b2-py2.6.egg
/Library/Python/2.6/site-packages/pyobjc_framework_WebKit-2.2b2- 
py2.6.egg
/Library/Python/2.6/site-packages/ 
pyobjc_framework_SystemConfiguration-2.2b2-py2.6-macosx-10.6- 
universal.egg
/Library/Python/2.6/site-packages/pyobjc_framework_SyncServices-2.2b2- 
py2.6.egg
/Library/Python/2.6/site-packages/pyobjc_framework_SearchKit-2.2b2- 
py2.6.egg
/Library/Python/2.6/site-packages/pyobjc_framework_ScreenSaver-2.2b2- 
py2.6-macosx-10.6-universal.egg
/Library/Frameworks/Python.framework/Versions/Current/bin
/Library/Frameworks/Python.framework/Versions/2.6/bin
/Library/Frameworks/Python.framework/Versions/3.0/bin
/Library/Frameworks/Python.framework/Versions/2.4/bin
/opt/local/bin
/opt/local/sbin
/sw/bin
/sw/sbin
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
/usr/X11/bin
/usr/X11R6/bin
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python26.zip
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/ 
python
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
lib-old
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
lib-dynload
/Library/Python/2.6/site-packages
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/ 
python/PyObjC
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/ 
python/wx-2.8-mac-unicode

It seems redundant in places and includes paths to other versions of  
python, but I can't see that there is a source for the problem there.

Is there anything else that might offer a clue?

Thanks

Seamus O'Shea
University of Lethbridge, iCORE, Cybera
(403) 315-2941
(403) 332-4545

On Sep 6, 2009, at Sun, Sep6, 6:10 , Ronald Oussoren wrote:

>
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> This seems to be a problem with Apple's copy of Python or with your
> machine.
>
> Could you try the following:
> * In terminal.app run /usr/bin/python
> * Then use 'import objc' from Python's prompt.
> * Does this work or does it give the same traceback (it works for me
> BTW).
>
> If importing objc from Python's prompt works: Try to do a clean  
> build of
> the application in Xcode (use Clean All and then perform a build).
>
> ----------
> resolution:  -> invalid
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6812>
> _______________________________________

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6812>
_______________________________________
-------------- next part --------------
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>(1) When running python (/usr/bin/python) in Terminal I am able to import objc successfully. I printed the directory to be sure it's complete</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">Seamuss-MacBook:~ seamus$ /usr/bin/python</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">Python 2.6.1 (r261:67515, Jul&nbsp;&nbsp;7 2009, 23:51:51)&nbsp;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">[GCC 4.2.1 (Apple Inc. build 5646)] on darwin</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">Type "help", "copyright", "credits" or "license" for more information.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">&gt;&gt;&gt; import objc</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">&gt;&gt;&gt; print dir(objc)</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; ">['Accessor', 'BadPrototypeError', 'CFToObject', 'Category', 'FSRef', 'FSSpec', 'IBAction', 'IBOutlet', 'IMP', 'LockError', 'MAC_OS_X_VERSION_10_1', ......</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Futura; "><br></div><div>(2) I restarted Xcode, did a "Clean all" and rebuilt the app, but I got this dump</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">"Running???</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>2009-09-07 12:25:39.355 First_PyObjC[2796:a0f] mainFilePath is /Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/main.py&nbsp;</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>2009-09-07 12:25:39.360 First_PyObjC[2796:a0f] pythonpath is (</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp; &nbsp;&nbsp;"/Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources",</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp; &nbsp;&nbsp;"/Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/PyObjC",</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp; &nbsp;&nbsp;"/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/"</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>)&nbsp;</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>Traceback (most recent call last):</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp;&nbsp;File "/Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/main.py", line 10, in &lt;module&gt;</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp; &nbsp;&nbsp;import objc</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp;&nbsp;File "/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/PyObjC/objc/__init__.py", line 22, in &lt;module&gt;</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp; &nbsp;&nbsp;_update()</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp;&nbsp;File "/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/PyObjC/objc/__init__.py", line 19, in _update</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp; &nbsp;&nbsp;import _objc</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>ImportError: dlopen(/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/PyObjC/objc/_objc.so, 2): Symbol not found: _PyType_Modified</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp;&nbsp;Referenced from: /System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/PyObjC/objc/_objc.so</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp;&nbsp;Expected in: flat namespace</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>&nbsp;in /System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/PyObjC/objc/_objc.so</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>2009-09-07 12:25:39.460 First_PyObjC[2796:a0f] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '/Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/main.m:46 main() PyRun_SimpleFile failed with file '/Users/seamus/Science/xcode exploration/Objc-programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/main.py'.&nbsp;&nbsp;See console for errors.'</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>*** Call stack at first throw:</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>(</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i><span class="Apple-tab-span" style="white-space: pre; ">	</span>0&nbsp;&nbsp;&nbsp;CoreFoundation&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;0x90a1858a __raiseError + 410</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i><span class="Apple-tab-span" style="white-space: pre; ">	</span>1&nbsp;&nbsp;&nbsp;libobjc.A.dylib&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;0x9309cf49 objc_exception_throw + 56</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i><span class="Apple-tab-span" style="white-space: pre; ">	</span>2&nbsp;&nbsp;&nbsp;CoreFoundation&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;0x90a182b8 +[NSException raise:format:arguments:] + 136</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i><span class="Apple-tab-span" style="white-space: pre; ">	</span>3&nbsp;&nbsp;&nbsp;CoreFoundation&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;0x90a1822a +[NSException raise:format:] + 58</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i><span class="Apple-tab-span" style="white-space: pre; ">	</span>4&nbsp;&nbsp;&nbsp;First_PyObjC&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;0x00002bc2 main + 1084</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i><span class="Apple-tab-span" style="white-space: pre; ">	</span>5&nbsp;&nbsp;&nbsp;First_PyObjC&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;0x0000275a start + 54</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><i>)</i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">sharedlibrary apply-load-rules all"</div></div><div><font class="Apple-style-span" face="Futura"><br></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px; ">It seems identical to the original problem.</span></font></div><div><font class="Apple-style-span" face="Futura"><br></font></div><div><font class="Apple-style-span" face="Futura">(3) I</font>&nbsp;wondered if there is something the PATH specifications that caused things to be misdirected during the build, so I printed sys.path out from within python.&nbsp;</div></div><div><br></div><div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc-2.2b2-py2.6.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc_framework_XgridFoundation-2.2b2-py2.6.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc_framework_WebKit-2.2b2-py2.6.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc_framework_SystemConfiguration-2.2b2-py2.6-macosx-10.6-universal.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc_framework_SyncServices-2.2b2-py2.6.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc_framework_SearchKit-2.2b2-py2.6.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages/pyobjc_framework_ScreenSaver-2.2b2-py2.6-macosx-10.6-universal.egg</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Frameworks/Python.framework/Versions/Current/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Frameworks/Python.framework/Versions/2.6/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Frameworks/Python.framework/Versions/3.0/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Frameworks/Python.framework/Versions/2.4/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/opt/local/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/opt/local/sbin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/sw/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/sw/sbin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/usr/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/usr/sbin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/sbin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/usr/local/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/usr/X11/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/usr/X11R6/bin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python26.zip</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-old</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/Library/Python/2.6/site-packages</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC</span></font></div><div><font class="Apple-style-span" face="Futura" size="3"><span class="Apple-style-span" style="font-size: 12px; ">/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode</span></font></div><div><br></div></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px; ">It seems redundant in places and includes paths to other versions of python, but I can't see that there is a source for the problem there.</span></font></div><div><br></div>Is there anything else that might offer a clue?&nbsp;<div><br></div><div><br></div><div>Thanks</div><div><br></div></div><div><br></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div><div><div>Seamus O'Shea</div><div>University of Lethbridge, iCORE, Cybera</div></div></div>(403) 315-2941<div>(403) 332-4545</div></span>
</div>
<br><div><div>On Sep 6, 2009, at Sun, Sep6, 6:10 , Ronald Oussoren wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>Ronald Oussoren &lt;<a href="mailto:ronaldoussoren at mac.com">ronaldoussoren at mac.com</a>&gt; added the comment:<br><br>This seems to be a problem with Apple's copy of Python or with your <br>machine.<br><br>Could you try the following:<br>* In terminal.app run /usr/bin/python<br>* Then use 'import objc' from Python's prompt.<br>* Does this work or does it give the same traceback (it works for me <br>BTW).<br><br>If importing objc from Python's prompt works: Try to do a clean build of <br>the application in Xcode (use Clean All and then perform a build).<br><br>----------<br>resolution: &nbsp;-&gt; invalid<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/issue6812">http://bugs.python.org/issue6812</a>&gt;<br>_______________________________________<br></div></blockquote></div><br></body></html>

From report at bugs.python.org  Mon Sep  7 21:04:12 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Sep 2009 19:04:12 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252350252.96.0.717959247392.issue6844@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Mon Sep  7 21:11:37 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Sep 2009 19:11:37 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252350697.76.0.667981478291.issue6844@psf.upfronthosting.co.za>


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

If someone can come up w/ a patch to make this work for all of you I would 
be happy to review it and backport to 2.6. But the deprecation warning 
cannot go away as it's needed for anyone who came to rely on the feature 
in their 2.5 code from Python.

----------

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

From report at bugs.python.org  Mon Sep  7 21:32:49 2009
From: report at bugs.python.org (loveminix)
Date: Mon, 07 Sep 2009 19:32:49 +0000
Subject: [issue6854] UnicodeDecodeError when retrieving binary data from
	cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1252351969.32.0.373994524514.issue6854@psf.upfronthosting.co.za>


loveminix <loveminix at yahoo.com.cn> added the comment:

Here is the trackback (the uploaded file is a PDF file):

UnicodeDecodeError Python 3.1.1: /home/chu7/software/bin/python3
Mon Sep 7 12:31:07 2009 

A problem occurred in a Python script. Here is the sequence of function 
calls leading up to the error, in the order they occurred.

 /home/chu7/web/cgi-bin/upload.py in () 
     35 );
 
     36 elif pathInfo == "/upload":
 
=>   37     fieldStorage = cgi.FieldStorage();
 
     38     fileItem = fieldStorage["file"];
 
     39     if fileItem.filename != "":
 
fieldStorage undefined, cgi = <module 'cgi' 
from '/home/chu7/software/lib/python3.1/cgi.py'>, cgi.FieldStorage = 
<class 'cgi.FieldStorage'> 
 /home/chu7/software/lib/python3.1/cgi.py in __init__(self=FieldStorage
(None, None, []), fp=None, headers={'content-length': '76784', 'content-
type': 'multipart/form-data; boundary=---------------------------
7d95563062a'}, outerboundary='', environ=<os._Environ object at 
0x8ee040c>, keep_blank_values=0, strict_parsing=0) 
    489             self.read_urlencoded()
 
    490         elif ctype[:10] == 'multipart/':
 
=>  491             self.read_multi(environ, keep_blank_values, 
strict_parsing)
 
    492         else:
 
    493             self.read_single()
 
self = FieldStorage(None, None, []), self.read_multi = <bound method 
FieldStorage.read_multi of FieldStorage(None, None, [])>, environ = 
<os._Environ object at 0x8ee040c>, keep_blank_values = 0, 
strict_parsing = 0 
 /home/chu7/software/lib/python3.1/cgi.py in read_multi
(self=FieldStorage(None, None, []), environ=<os._Environ object at 
0x8ee040c>, keep_blank_values=0, strict_parsing=0) 
    609         # Create bogus content-type header for proper multipart 
parsing
 
    610         parser.feed('Content-Type: %s; boundary=%s\r\n\r\n' % 
(self.type, ib))
 
=>  611         parser.feed(self.fp.read())
 
    612         full_msg = parser.close()
 
    613         # Get subparts
 
parser = <email.feedparser.FeedParser object at 0x910daac>, parser.feed 
= <bound method FeedParser.feed of <email.feedparser.FeedParser object 
at 0x910daac>>, self = FieldStorage(None, None, []), self.fp = 
<_io.TextIOWrapper name='<stdin>' encoding='ANSI_X3.4-1968'>, 
self.fp.read = <built-in method read of _io.TextIOWrapper object at 
0x8ee833c> 
 /home/chu7/software/lib/python3.1/encodings/ascii.py in decode
(self=<encodings.ascii.IncrementalDecoder object at 0x8f6b74c>, 
input=b'-----------------------------7d95563062a\r\nCo...\n-------------
----------------7d95563062a--\r\n', final=True) 
     24 class IncrementalDecoder(codecs.IncrementalDecoder):
 
     25     def decode(self, input, final=False):
 
=>   26         return codecs.ascii_decode(input, self.errors)[0]
 
     27 
 
     28 class StreamWriter(Codec,codecs.StreamWriter):
 
global codecs = <module 'codecs' 
from '/home/chu7/software/lib/python3.1/codecs.py'>, 
codecs.ascii_decode = <built-in function ascii_decode>, input = b'------
-----------------------7d95563062a\r\nCo...\n---------------------------
--7d95563062a--\r\n', self = <encodings.ascii.IncrementalDecoder object 
at 0x8f6b74c>, self.errors = 'strict' 

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc7 in position 
158: ordinal not in range(128) 
      args = ('ascii', b'-----------------------------
7d95563062a\r\nCo...\n-----------------------------7d95563062a--\r\n', 
158, 159, 'ordinal not in range(128)') 
      encoding = 'ascii' 
      end = 159 
      object = b'-----------------------------7d95563062a\r\nCo...\n----
-------------------------7d95563062a--\r\n' 
      reason = 'ordinal not in range(128)' 
      start = 158 
      with_traceback = <built-in method with_traceback of 
UnicodeDecodeError object at 0x905bd2c>

----------

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

From report at bugs.python.org  Mon Sep  7 21:35:28 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 07 Sep 2009 19:35:28 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252352128.04.0.786874608236.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

After looking at this more carefully, I find myself wondering what
exactly is being deprecated at all.

Brett said:
> it's needed for anyone who came to rely on the feature  in their 2.5
code from Python.

Can someone help me understand what the feature is?

----------

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

From report at bugs.python.org  Mon Sep  7 21:44:26 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Sep 2009 19:44:26 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252352128.04.0.786874608236.issue6844@psf.upfronthosting.co.za>
Message-ID: <bbaeab100909071242l56dc9022r345b74197330be77@mail.gmail.com>


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

On Mon, Sep 7, 2009 at 12:35, Jean-Paul Calderone<report at bugs.python.org> wrote:
>
> Jean-Paul Calderone <exarkun at divmod.com> added the comment:
>
> After looking at this more carefully, I find myself wondering what
> exactly is being deprecated at all.

The message attribute as introduced in Python 2.5 based on
http://www.python.org/dev/peps/pep-0348/ .

>
> Brett said:
>> it's needed for anyone who came to rely on the feature ?in their 2.5
> code from Python.
>
> Can someone help me understand what the feature is?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6844>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Sep  7 22:01:49 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 07 Sep 2009 20:01:49 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252353709.33.0.37505035771.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Hm.  That PEP is marked as rejected, though.  I guess it was partially
implemented, those changes included in the Python 2.5 release, and then
it was decided that it was a bad idea, rejected, and the changes undone
for 3.x (what about 2.7)?  Or did something else happen?

I did a simple search on the PEP for the word "message", but the word
doesn't appear anywhere in the text!  So I guess it's a feature that's
implied by the PEP, but I would appreciate some help figuring out the
implication.

Here's what I do see:

  - If one argument is passed to BaseException.__init__, then the value
is used as the value for the message attribute.
  - If zero or more than one arguments are passed, then the attribute is
given the empty string for a value.
  - If zero or one arguments are passed, the message attribute is used
as the string representation of the exception instance.

The deprecation warning emitted in 2.6 doesn't tell me which of these
things is deprecated, though.  Is there something more to the message
attribute, or are one or more of the above list things which should no
longer be relied on?

----------

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

From report at bugs.python.org  Mon Sep  7 22:10:30 2009
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 07 Sep 2009 20:10:30 +0000
Subject: [issue6719] pdb messes up when debugging an non-ascii program
In-Reply-To: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>
Message-ID: <1252354230.59.0.513230889522.issue6719@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Here is what's happening: when pdb starts up it sets tracing and several
trace events happen before the pdb reaches the first line of the
debugged program. So, pdb has some logic to ignore certain events on
startup (_wait_for_main_pyfile).

On normal startup only "call" and "line"events need to be ignored and so
that's what pdb did. However, the "coding" directive causes some
additional code to get executed and results in "return" and "exception"
events.

I am attaching the patch to properly ignore irrelevant "return" and
"exception"events on startup. The patch fixes both the startup and the
exit problems.

----------
nosy: +isandler
Added file: http://bugs.python.org/file14856/pdb-nonascii.patch.v1

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

From report at bugs.python.org  Mon Sep  7 22:32:49 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Sep 2009 20:32:49 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252353709.33.0.37505035771.issue6844@psf.upfronthosting.co.za>
Message-ID: <bbaeab100909071332l24cc3773tc59e0df79afce22e@mail.gmail.com>


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

On Mon, Sep 7, 2009 at 13:01, Jean-Paul Calderone<report at bugs.python.org> wrote:
>
> Jean-Paul Calderone <exarkun at divmod.com> added the comment:
>
> Hm. ?That PEP is marked as rejected, though. ?I guess it was partially
> implemented, those changes included in the Python 2.5 release, and then
> it was decided that it was a bad idea, rejected, and the changes undone
> for 3.x (what about 2.7)? ?Or did something else happen?
>

I screwed up and pasted in the URL for the wrong PEP. Sorry about
that. Written a few too many PEPs involving exceptions. The correct
one is http://www.python.org/dev/peps/pep-0352/ .

> I did a simple search on the PEP for the word "message", but the word
> doesn't appear anywhere in the text! ?So I guess it's a feature that's
> implied by the PEP, but I would appreciate some help figuring out the
> implication.
>
> Here's what I do see:
>
> ?- If one argument is passed to BaseException.__init__, then the value
> is used as the value for the message attribute.
> ?- If zero or more than one arguments are passed, then the attribute is
> given the empty string for a value.
> ?- If zero or one arguments are passed, the message attribute is used
> as the string representation of the exception instance.
>
> The deprecation warning emitted in 2.6 doesn't tell me which of these
> things is deprecated, though. ?Is there something more to the message
> attribute, or are one or more of the above list things which should no
> longer be relied on?

The 'message' attribute itself is deprecated as it didn't exist prior
to being introduced in 2.5. The original idea was to not let
BaseException take multiple arguments to its constructor and have
message be what replaced 'args'. But when I tried to do that at PyCon
2007 the pain was too great so it was decided a more long-term
strategy to making BaseException accept a single argument was needed.
So the 'message' attribute that got added to BaseException was
retracted.

----------

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

From report at bugs.python.org  Mon Sep  7 22:34:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Sep 2009 20:34:41 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252355681.0.0.909401641427.issue6844@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Mon Sep  7 22:35:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Sep 2009 20:35:14 +0000
Subject: [issue6849] Tutorial changes
In-Reply-To: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
Message-ID: <1252355714.27.0.0280555907863.issue6849@psf.upfronthosting.co.za>


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

I've already renamed the message attribute in the 2.x tutorial in trunk.

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

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

From report at bugs.python.org  Mon Sep  7 23:53:31 2009
From: report at bugs.python.org (Alan Isaac)
Date: Mon, 07 Sep 2009 21:53:31 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252360411.22.0.479510034218.issue6844@psf.upfronthosting.co.za>


Alan Isaac <alan.isaac at gmail.com> added the comment:

> The 'message' attribute itself is deprecated
> as it didn't exist prior to being introduced in 2.5.

That seems to me to be the wrong way to phrase it, and indeed that kind
of phrasing implies the current bug.  For example, it leads to the
incorrect statement that "The 'message' attribute ... didn't exist prior
to being introduced in 2.5."  But looking at the docutils and Twisted
code bases, to take two examples, tells us that it **did** exist: a slew
of instances had this attribute.  The correct statement, that
BaseException did not initialize a `message` attribute, is an entirely
different matter.

Imo, deprecating setting and accessing an **instance attribute** is just
flat out wrong and grossly violates inheritability promises.  As we have
seen.

I think (?) that what was desired to be deprecated is the combination of

- setting a message attribute via BaseException.__init__, AND
- accessing an instances message attribute that was set *this way*

But in fact the setting cannot really be deprecated because it is
implicit: it is something currently done by BaseException, not by the
user.  So I think (?) the best we can do is look at whether the user
initializes BaseException (**not** the derived classes) with a single
argument, which is a nonempty string, and then tries to access this as a
`message` attribute.  Which is why I originally proposed setting a flag
when BaseException.__init__ is called and conditioning the deprecation
warning on this flag.  (E.g., the flag could be set if and only if the
user calls BaseException.__init__(instance, string).)

In any case, I think Jean-Paul is asking exactly the right question
(i.e., just what exactly is being deprecated?).  A more careful answer
will hopefully lead to less buggy DeprecationWarning.

----------

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

From report at bugs.python.org  Mon Sep  7 23:57:55 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 07 Sep 2009 21:57:55 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252360675.56.0.45055871137.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Alright.  So in Python 3.1, this is the behavior:

>>> BaseException().message
(attribute error)
>>> BaseException("foo").message
(attribute error)
>>> BaseException("foo", "bar").message
(attribute error)
>>> x = BaseException()
>>> x.message = "foo"
>>> x.message
'foo'
>>> x = BaseException("foo")
>>> x.message = "bar"
>>> x.message
'bar'
>>> x = BaseException("foo")
>>> x.message = "bar"
>>> x.message
'bar'

So I propose the following as the new behavior for 2.x:

>>> BaseException().message
(deprecation warning)
''
>>> BaseException("foo").message
(deprecation warning)
'foo'
>>> BaseException("foo", "bar").message
(deprecation warning)
''
>>> x = BaseException()
>>> x.message = "foo"
>>> x.message
'foo'
>>> x = BaseException("foo")
>>> x.message = "bar"
>>> x.message
'bar'
>>> x = BaseException("foo", "bar")
>>> x.message = "baz"
>>> x.message
'baz'

Summarized: emit a warning when the same code in Python 3.1 would raise
an exception; let all other cases pass.

There is one other case that I would think about changing, but I don't
see how it can, given the behavior that is implemented in 3.1 already. 
BaseException("a message") is a Python 2.5-supported way of creating an
exception with a value for its message attribute.  This no longer works
in Python 3.1.  So, arguably, this is another case where a deprecation
warning should be emitted.  However, this would be pretty obnoxious,
since BaseException("a message") in Python 2.4 (by way of Exception("a
message"), of course, since Python 2.4 did not have BaseException) was
perfectly valid.  It seems like BaseException(string) should have been
deprecated and BaseException(tuple) been made the preferred API.  That's
for another time, though.

How does the above proposed deprecation behavior sound?

----------

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

From report at bugs.python.org  Tue Sep  8 00:07:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Sep 2009 22:07:55 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252360675.56.0.45055871137.issue6844@psf.upfronthosting.co.za>
Message-ID: <bbaeab100909071507m670756d7oa233cd7d3aed1f81@mail.gmail.com>


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

On Mon, Sep 7, 2009 at 14:57, Jean-Paul Calderone<report at bugs.python.org> wrote:
>
> Jean-Paul Calderone <exarkun at divmod.com> added the comment:
>
> Alright. ?So in Python 3.1, this is the behavior:
>
>>>> BaseException().message
> (attribute error)
>>>> BaseException("foo").message
> (attribute error)
>>>> BaseException("foo", "bar").message
> (attribute error)
>>>> x = BaseException()
>>>> x.message = "foo"
>>>> x.message
> 'foo'
>>>> x = BaseException("foo")
>>>> x.message = "bar"
>>>> x.message
> 'bar'
>>>> x = BaseException("foo")
>>>> x.message = "bar"
>>>> x.message
> 'bar'
>
> So I propose the following as the new behavior for 2.x:
>
>>>> BaseException().message
> (deprecation warning)
> ''
>>>> BaseException("foo").message
> (deprecation warning)
> 'foo'
>>>> BaseException("foo", "bar").message
> (deprecation warning)
> ''
>>>> x = BaseException()
>>>> x.message = "foo"
>>>> x.message
> 'foo'
>>>> x = BaseException("foo")
>>>> x.message = "bar"
>>>> x.message
> 'bar'
>>>> x = BaseException("foo", "bar")
>>>> x.message = "baz"
>>>> x.message
> 'baz'
>
> Summarized: emit a warning when the same code in Python 3.1 would raise
> an exception; let all other cases pass.
>
> There is one other case that I would think about changing, but I don't
> see how it can, given the behavior that is implemented in 3.1 already.
> BaseException("a message") is a Python 2.5-supported way of creating an
> exception with a value for its message attribute. ?This no longer works
> in Python 3.1. ?So, arguably, this is another case where a deprecation
> warning should be emitted. ?However, this would be pretty obnoxious,
> since BaseException("a message") in Python 2.4 (by way of Exception("a
> message"), of course, since Python 2.4 did not have BaseException) was
> perfectly valid. ?It seems like BaseException(string) should have been
> deprecated and BaseException(tuple) been made the preferred API. ?That's
> for another time, though.
>
> How does the above proposed deprecation behavior sound?

Works for me. If someone can create a patch for that I will review it
and apply it to 2.6 (the warning will be removed from 2.7 and so will
the attribute).

----------

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

From report at bugs.python.org  Tue Sep  8 01:00:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:00:38 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252364438.17.0.238232538315.issue6713@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file14857/bench_long_format.py

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

From report at bugs.python.org  Tue Sep  8 01:07:53 2009
From: report at bugs.python.org (gert cuykens)
Date: Mon, 07 Sep 2009 23:07:53 +0000
Subject: [issue6858] This is a python file, apply syntax highlighting
In-Reply-To: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>
Message-ID: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>


New submission from gert cuykens <gert.cuykens at gmail.com>:

http://groups.google.be/group/comp.lang.python/browse_thread/thread/252fa1ccd0251977#

Menu option please, so I can highlight .wsgi .txt .xml files with python
code in it, does not matter if non python code gets wrongly highlighted too.

----------
components: IDLE
messages: 92395
nosy: gert
severity: normal
status: open
title: This is a python file, apply syntax highlighting
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Sep  8 01:08:18 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Mon, 07 Sep 2009 23:08:18 +0000
Subject: [issue6811] add a filename argument to marshal.load*
In-Reply-To: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>
Message-ID: <1252364898.94.0.651127216116.issue6811@psf.upfronthosting.co.za>


Changes by Frank Wierzbicki <fwierzbicki at gmail.com>:


----------
nosy: +fwierzbicki

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

From report at bugs.python.org  Tue Sep  8 01:13:03 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:13:03 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252365183.35.0.251572523045.issue6713@psf.upfronthosting.co.za>


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

I wrote a dummy script to generate a big number (2568 decimal digits, 8530
bits) and then benchmark str(n). Results on my computer:

Python 2.7a0, Pentium4 @ 3.0 GHz (32 bits), long base=2^15

Smallest value of 5 runs:

  original = 5046.8 ms
  patched = 2032.4 ms

For huge numbers, the patch is much (60%) faster.

--

Small integer (type=int) : n=factorial(10) (22 bits, 7 decimal digits) with
100000 loops.

   original = 861.7 ms
   patched = 639.2 ms

It's also faster (26%).

--

And with n=1 (1 bit, 1 decimal digit), type=int :

  original = 606.7
  patched = 561.6

It's a little bit faster (7%) with the patch.

I don't see any performance regression, only good improvements: 60% faster
to huge numbers.

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

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

From report at bugs.python.org  Tue Sep  8 01:15:08 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:15:08 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252365308.1.0.853866532911.issue6713@psf.upfronthosting.co.za>


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

By benchmark should be reproduced on a 64 bits CPU with 2^15 and 2^30
bases for the long type.

----------

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

From report at bugs.python.org  Tue Sep  8 01:19:05 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:19:05 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252365545.74.0.713388851994.issue6713@psf.upfronthosting.co.za>


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

Would it be possible to share some constant data between intobject.c and
longobject.c? There is already "static const unsigned char BitLengthTable[32]"
(32 bytes), and the patch introduces "static const char _decimal_digit_table[]"
(100 bytes).

----------

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

From report at bugs.python.org  Tue Sep  8 01:21:35 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:21:35 +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: <1252365695.3.0.683823130901.issue5705@psf.upfronthosting.co.za>


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

@boya: It's maybe better to open a new issue for posix_lchown.

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

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

From report at bugs.python.org  Tue Sep  8 01:27:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:27:38 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1252366058.17.0.583904477684.issue5080@psf.upfronthosting.co.za>


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

+10. It would fix the os.urandom(1.2) bug. On Linux, os.urandom() displays
the following warnings and then go into an unlimited loop...

/usr/lib/python2.5/os.py:734: DeprecationWarning: integer argument expected,
got float
  bytes += read(_urandomfd, n - len(bytes))

read(1.2 - 1) ~> read(0.2) ~> read(0)...

Tolerate float as integers introduces "subtle" bugs like byte/unicode bugs...

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

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

From report at bugs.python.org  Tue Sep  8 01:34:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:34:56 +0000
Subject: [issue6817] char buffer in function posix_getcwdu should not be fix
	length
In-Reply-To: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>
Message-ID: <1252366496.03.0.852610470398.issue6817@psf.upfronthosting.co.za>


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

Your patch is mixing tabs and spaces :-/

A "free(tmpbuf);" is missing in "if (res == NULL) return posix_error();".

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

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

From report at bugs.python.org  Tue Sep  8 01:41:26 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:41:26 +0000
Subject: [issue6817] char buffer in function posix_getcwdu should not be fix
	length
In-Reply-To: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>
Message-ID: <1252366886.26.0.132828809391.issue6817@psf.upfronthosting.co.za>


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

The "#ifdef MS_WINDOWS" is not a the right place in posix_getcwdu(): buf and
res are declared but unused, and there is dead code on Windows.

The patch only fixes the UNIX implementation, not the Windows
implementation.

In the py3k branch, bytes and unicode versions of getcwd are factorized in a
common function. The same should be done in python trunk.

----------

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

From report at bugs.python.org  Tue Sep  8 01:44:22 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Mon, 07 Sep 2009 23:44:22 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1252367062.55.0.183839159612.issue6816@psf.upfronthosting.co.za>


Changes by Frank Wierzbicki <fwierzbicki at gmail.com>:


----------
nosy: +fwierzbicki

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

From report at bugs.python.org  Tue Sep  8 01:58:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:58:09 +0000
Subject: [issue6859] stdint (eg. uint64_t) for ctypes
In-Reply-To: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za>
Message-ID: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za>


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

It would be nice to have (at least) some stdint.h types in ctypes:
- uint8_t, int8_t
- int16_t, uint16_t
- int32_t, uint32_t
- uint64_t, int64_t

Attached fle is a Python implementation of that.

stdint.h contains much more types, but I don't think that
(u)int_leastXX_t/(u)int_fastXX_t are used in public structures/functions.

Other interesting types/constants from stdint.h:
- intptr_t / uintptr_t
- (U)INT(8|16|32|64)_(MIN|MAX)
- PTRDIFF_MAX

----------
components: Extension Modules
files: stdint.py
messages: 92403
nosy: haypo
severity: normal
status: open
title: stdint (eg. uint64_t) for ctypes
type: feature request
Added file: http://bugs.python.org/file14858/stdint.py

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

From report at bugs.python.org  Tue Sep  8 02:00:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Sep 2009 00:00:22 +0000
Subject: [issue6859] stdint (eg. uint64_t) for ctypes
In-Reply-To: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za>
Message-ID: <1252368022.52.0.804132084835.issue6859@psf.upfronthosting.co.za>


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

Oooh. I just see that ctypes already includes ctypes.c_(u)int(8|16|32|64)
types... Sorry for the noise :-)

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

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

From report at bugs.python.org  Tue Sep  8 02:00:34 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Sep 2009 00:00:34 +0000
Subject: [issue6859] stdint (eg. uint64_t) for ctypes
In-Reply-To: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za>
Message-ID: <1252368034.9.0.870998514629.issue6859@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  8 02:06:07 2009
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 08 Sep 2009 00:06:07 +0000
Subject: [issue6858] This is a python file, apply syntax highlighting
In-Reply-To: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>
Message-ID: <1252368367.93.0.288150505356.issue6858@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/issue6858>
_______________________________________

From report at bugs.python.org  Tue Sep  8 03:01:29 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 08 Sep 2009 01:01:29 +0000
Subject: [issue6858] This is a python file, apply syntax highlighting
In-Reply-To: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>
Message-ID: <1252371689.57.0.591890321911.issue6858@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

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

From report at bugs.python.org  Tue Sep  8 03:08:34 2009
From: report at bugs.python.org (=?utf-8?q?Patrick_N=C3=A4f?=)
Date: Tue, 08 Sep 2009 01:08:34 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>


New submission from Patrick N?f <herzbube at herzbube.ch>:

The attached setup.py file defines a custom command named "test", which
is implemented in a class named "TestClass". Try to run both of the
following:

1) ./setup.py test -h
2) ./setup.py --help-commands

In case 1, Distutils will use the class name to print the help output.
In case 2, it will use the command name. This behaviour is inconsistent.
As a developer, if I want to get the output right in both cases, I am
forced to use the same name both for the command class and the command
name (a string in a dictionary).

I propose that Distutils always use the command name. Besides fixing the
inconsistency, this solution gives the freedom to choose class names
back to the developer.

I have tested this behaviour on Mac OS X 10.5, both with the
system-provided Python 2.5 and custom-installed versions of Python 2.6
and 3.1.

----------
assignee: tarek
components: Distutils
files: setup.py
messages: 92405
nosy: herzbube, tarek
severity: normal
status: open
title: Inconsistent naming of custom command in setup.py help output
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14859/setup.py

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

From report at bugs.python.org  Tue Sep  8 03:56:16 2009
From: report at bugs.python.org (kai zhu)
Date: Tue, 08 Sep 2009 01:56:16 +0000
Subject: [issue6861] bytearray.__new__ doesn't subclass
In-Reply-To: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za>
Message-ID: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

# a00.py

parent = bytearray # fails
# parent = bytes   # works
# parent = str     # works

class Foo(parent):

  def __new__(klass, x): return parent.__new__(klass, x)

Foo(x = None)



$ python3.1 -c "import a00"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "a00.py", line 11, in <module>
    Foo(x = None)
TypeError: 'x' is an invalid keyword argument for this function
lethe 3 /tmp/kaizhu/Python-3.1.1:

----------
components: Interpreter Core, Library (Lib)
messages: 92406
nosy: kaizhu
severity: normal
status: open
title: bytearray.__new__ doesn't subclass
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Sep  8 04:06:51 2009
From: report at bugs.python.org (Brandon Height)
Date: Tue, 08 Sep 2009 02:06:51 +0000
Subject: [issue6861] bytearray.__new__ doesn't subclass
In-Reply-To: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za>
Message-ID: <1252375611.7.0.147551345182.issue6861@psf.upfronthosting.co.za>


Brandon Height <bmheight at gmail.com> added the comment:

This behavior is also found inside of version 2.6.2

----------
nosy: +lasko

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

From report at bugs.python.org  Tue Sep  8 04:16:05 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Sep 2009 02:16:05 +0000
Subject: [issue6861] bytearray.__new__ doesn't subclass
In-Reply-To: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za>
Message-ID: <1252376165.57.0.937145386422.issue6861@psf.upfronthosting.co.za>


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

That's because bytearray is mutable, so it uses __init__ instead of __new__.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Sep  8 07:23:40 2009
From: report at bugs.python.org (Chris Miles)
Date: Tue, 08 Sep 2009 05:23:40 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1252387420.13.0.502007993909.issue2320@psf.upfronthosting.co.za>


Changes by Chris Miles <miles.chris at gmail.com>:


----------
nosy: +chrismiles

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

From report at bugs.python.org  Tue Sep  8 09:22:08 2009
From: report at bugs.python.org (john zeng)
Date: Tue, 08 Sep 2009 07:22:08 +0000
Subject: [issue6862] exec(), locals() and local variable access
In-Reply-To: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za>
Message-ID: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za>


New submission from john zeng <ooev at 163.com>:

Can you help me understand why variable `u' is not accessible after 
exec()? Is this sort of a late binding issue?

def test(v1):
    print(v1)
    print("Before exec(): " + str(locals()))
    exec(v1)
    print("After  exec(): " + str(locals()))
#   This fails:
#    print(u)
#   This is workaround:
    en = locals()['u']
    print(en)

v1="u=4"
test(v1)

----------
components: Interpreter Core
messages: 92409
nosy: ooev
severity: normal
status: open
title: exec(), locals() and local variable access
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Sep  8 10:20:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Sep 2009 08:20:33 +0000
Subject: [issue6862] exec(), locals() and local variable access
In-Reply-To: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za>
Message-ID: <1252398033.47.0.651536460417.issue6862@psf.upfronthosting.co.za>


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

When the parser analyzes the test() function, it determines that 'u' in
"print(u)" is a global variable. But exec modifies the local namespace...

You could add a "u=None" near the start of the function, or better,
always use a namespace for the exec statement:

d = {}
exec v1 in d
en = d['u']

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Tue Sep  8 10:57:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Sep 2009 08:57:20 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1252400240.88.0.367369337915.issue1578269@psf.upfronthosting.co.za>


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

Your patch re-adds the compatibility code with Windows 95
(unicode_file_names, check_gfax...), which has been removed two months
ago, see r73603 and r73675. Please remove it!

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

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

From report at bugs.python.org  Tue Sep  8 13:08:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Sep 2009 11:08:43 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1252408123.54.0.535754065401.issue6804@psf.upfronthosting.co.za>


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

This makes sense, but the code should:
- not make the query when the extension is empty
- catch the WindowsError raised when the extension is not in the registry.

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

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

From report at bugs.python.org  Tue Sep  8 13:19:23 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 08 Sep 2009 11:19:23 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <1252400240.88.0.367369337915.issue1578269@psf.upfronthosting.co.za>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B6A04AF4C2BC@hornigold>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Indeed. I see that now. I'll track down how that happened and see that we 
avoid regression.

> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Your patch re-adds the compatibility code with Windows 95
> (unicode_file_names, check_gfax...), which has been removed two months
> ago, see r73603 and r73675. Please remove it!

----------
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/file14860/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/20090908/9dda5492/attachment.bin>

From report at bugs.python.org  Tue Sep  8 15:05:39 2009
From: report at bugs.python.org (=?utf-8?q?Pertti_Kellom=C3=A4ki?=)
Date: Tue, 08 Sep 2009 13:05:39 +0000
Subject: [issue6863] Wrong linker command if CXX set to "ccache g++"
In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
Message-ID: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>


New submission from Pertti Kellom?ki <pertti.kellomaki at tut.fi>:

If the compiler command in CXX contains more than one word, e.g. "ccache
g++", line 256 in distutils/unixccompiler.py only picks the first word
as the linker and discards the rest:

                    linker[i] = self.compiler_cxx[i]

On Ubuntu 9.04 the values of the variables are:

(Pdb) print linker
['gcc', '-pthread', '-shared', '-Wl,-O1', '-Wl,-Bsymbolic-functions']
(Pdb) print self.compiler_cxx
['ccache', 'g++']
(Pdb)

----------
assignee: tarek
components: Distutils
messages: 92414
nosy: perttikellomaki, tarek
severity: normal
status: open
title: Wrong linker command if CXX set to "ccache g++"
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  8 15:37:25 2009
From: report at bugs.python.org (dpogg1)
Date: Tue, 08 Sep 2009 13:37:25 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>


New submission from dpogg1 <dan.poggi at gmail.com>:

IDLE 2.6.1 locks up on Mac OS 10.6 when running using Apple's built-in 
version of Python (also 2.6.1) when creating a new buffer window or 
attempting to run/debug an existing file.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 92415
nosy: dpogg1, ronaldoussoren
severity: normal
status: open
title: IDLE 2.6.1 locks up on Mac OS 10.6
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  8 15:42:27 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Sep 2009 13:42:27 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1252417347.6.0.441988152958.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

If I understand you correctly the same also happens with the current 
version in subversion.

To reproduce:
* Start IDLE.app
* Open a new window

The new window opens, but (1) without a proper titlebar, and (2) this 
makes it impossible to further interact with IDLE (and that includes 
quiting the application).

----------

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

From report at bugs.python.org  Tue Sep  8 16:04:38 2009
From: report at bugs.python.org (dpogg1)
Date: Tue, 08 Sep 2009 14:04:38 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1252418678.97.0.407386130988.issue6864@psf.upfronthosting.co.za>


dpogg1 <dan.poggi at gmail.com> added the comment:

I can confirm this is the same issue.

----------

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

From report at bugs.python.org  Tue Sep  8 16:43:05 2009
From: report at bugs.python.org (Richard Shapiro)
Date: Tue, 08 Sep 2009 14:43:05 +0000
Subject: [issue6823] time.strftime does unnecessary range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1252420985.69.0.912324758726.issue6823@psf.upfronthosting.co.za>


Richard Shapiro <rashapiro83 at gmail.com> added the comment:

Here's a patch to normalize the results of the various system calls
which return time information. This was against the source for Python 2.5.1.

*** timemodule.c	Tue Sep  8 10:28:31 2009
--- /home/rshapiro/216/redist/Python-2.5.1/Modules/timemodule.c.dist	Mon
Jan 12 22:53:07 2009
***************
*** 241,247 ****
  static PyObject *
  tmtotuple(struct tm *p)
  {
-         long dstval;
  	PyObject *v = PyStructSequence_New(&StructTimeType);
  	if (v == NULL)
  		return NULL;
--- 241,246 ----
***************
*** 256,271 ****
  	SET(5, p->tm_sec);
  	SET(6, (p->tm_wday + 6) % 7); /* Want Monday == 0 */
  	SET(7, p->tm_yday + 1);	   /* Want January, 1 == 1 */
!         /* Alas, on some platforms tm_isdst can be something other
than -1, 0, or 1 */
!         if (p->tm_isdst < 0) {
!           dstval = -1;
!         } else if (p->tm_isdst > 0) {
!           dstval = 1;
!         } else {
!           dstval = 0;
!         }
! 
! 	SET(8, dstval);
  #undef SET
  	if (PyErr_Occurred()) {
  		Py_XDECREF(v);
--- 255,261 ----
  	SET(5, p->tm_sec);
  	SET(6, (p->tm_wday + 6) % 7); /* Want Monday == 0 */
  	SET(7, p->tm_yday + 1);	   /* Want January, 1 == 1 */
! 	SET(8, p->tm_isdst);
  #undef SET
  	if (PyErr_Occurred()) {
  		Py_XDECREF(v);
(t)neo:/home/rshapiro/216/redist/patch/Python-2.5.1/Modules 140 %

----------

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

From report at bugs.python.org  Tue Sep  8 16:52:19 2009
From: report at bugs.python.org (=?utf-8?q?Matthieu_Labb=C3=A9?=)
Date: Tue, 08 Sep 2009 14:52:19 +0000
Subject: [issue4485] fast swap of "default" Windows python versions
In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za>
Message-ID: <1252421539.24.0.359843123327.issue4485@psf.upfronthosting.co.za>


Changes by Matthieu Labb? <bugs.python.org at mattlabbe.com>:


----------
nosy: +matthieu.labbe

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

From report at bugs.python.org  Tue Sep  8 16:57:22 2009
From: report at bugs.python.org (=?utf-8?q?Matthieu_Labb=C3=A9?=)
Date: Tue, 08 Sep 2009 14:57:22 +0000
Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict
Message-ID: <1252421842.12.0.73210678684.issue1475692@psf.upfronthosting.co.za>


Changes by Matthieu Labb? <bugs.python.org at mattlabbe.com>:


----------
nosy: +matthieu.labbe
versions: +Python 2.4, Python 2.5

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

From report at bugs.python.org  Tue Sep  8 16:59:03 2009
From: report at bugs.python.org (=?utf-8?q?Matthieu_Labb=C3=A9?=)
Date: Tue, 08 Sep 2009 14:59:03 +0000
Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict
Message-ID: <1252421943.61.0.186635257883.issue1475692@psf.upfronthosting.co.za>


Changes by Matthieu Labb? <bugs.python.org at mattlabbe.com>:


----------
type: feature request -> behavior

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

From report at bugs.python.org  Tue Sep  8 17:09:33 2009
From: report at bugs.python.org (=?utf-8?q?Matthieu_Labb=C3=A9?=)
Date: Tue, 08 Sep 2009 15:09:33 +0000
Subject: [issue5397] PEP 372:  OrderedDict
In-Reply-To: <1235903426.27.0.376128912816.issue5397@psf.upfronthosting.co.za>
Message-ID: <1252422573.66.0.0096748895595.issue5397@psf.upfronthosting.co.za>


Changes by Matthieu Labb? <bugs.python.org at mattlabbe.com>:


----------
nosy: +matthieu.labbe

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

From report at bugs.python.org  Tue Sep  8 17:25:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Sep 2009 15:25:51 +0000
Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict
Message-ID: <1252423551.96.0.879797840155.issue1475692@psf.upfronthosting.co.za>


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

2.5 and 2.4 are in security-fix-only mode, so we don't set them in
versions since bugs won't get fixed there.

I don't think overridden methods should be called, since that would slow
down attribute lookup, which is already a bottleneck in Python.  Whether
there should be an error message is a more complicated question, and I'd
have to look at how this is implemented to even have an opinion on that.

----------
nosy: +r.david.murray
priority: normal -> low
versions: +Python 2.6, Python 3.2 -Python 2.4, Python 2.5

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

From report at bugs.python.org  Tue Sep  8 17:39:25 2009
From: report at bugs.python.org (John Posner)
Date: Tue, 08 Sep 2009 15:39:25 +0000
Subject: [issue5621] Add description of special case to "Assignment
	statements" section
In-Reply-To: <1238510706.85.0.278195682658.issue5621@psf.upfronthosting.co.za>
Message-ID: <1252424365.53.0.194543168038.issue5621@psf.upfronthosting.co.za>


John Posner <jjposner at optimum.net> added the comment:

George, here is a patch file for this bug. It modifies file
doc/reference/simple_stmts.rst

Please let me know if this was the wrong way to submit the patch file.

----------
keywords: +patch
status: pending -> open
Added file: http://bugs.python.org/file14861/assignment_statement.diff

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

From report at bugs.python.org  Tue Sep  8 17:39:55 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Sep 2009 15:39:55 +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: <1252424395.35.0.575351160507.issue6075@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm about to test the patches on a 10.4 system with Tk 8.4 and will report 
back with the results.

These patches might be useful to issue 6864, that issue says IDLE blocks 
on 10.6 and that problem seems to be fixed in python-trunk + Kevin's 
patches (although I haven't tested the trunk without these patches).

----------

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

From report at bugs.python.org  Tue Sep  8 18:17:41 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 08 Sep 2009 16:17:41 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1252426661.35.0.414550546701.issue6071@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Can this ticket be marked as a release blocker so it's not forgotten
about for 2.7?

----------

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

From report at bugs.python.org  Tue Sep  8 18:32:01 2009
From: report at bugs.python.org (=?utf-8?q?Pertti_Kellom=C3=A4ki?=)
Date: Tue, 08 Sep 2009 16:32:01 +0000
Subject: [issue6863] Wrong linker command if CXX set to "ccache g++"
In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
Message-ID: <1252427521.59.0.242580695891.issue6863@psf.upfronthosting.co.za>


Pertti Kellom?ki <pertti.kellomaki at tut.fi> added the comment:

This patch seems to solve the problem for me. I think it should also
work with the environment variable setting on OS X, but I haven't tested it.

----------
keywords: +patch
Added file: http://bugs.python.org/file14862/linker_command.patch

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

From report at bugs.python.org  Tue Sep  8 18:53:02 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Sep 2009 16:53:02 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1252428782.85.0.75208743186.issue6239@psf.upfronthosting.co.za>


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

> Commited as svn rev 74664 (py3k) and rev 74665 (release31-maint).

@theller: Cool, thanks ;-)

----------

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

From report at bugs.python.org  Tue Sep  8 19:00:16 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Sep 2009 17:00:16 +0000
Subject: [issue6823] time.strftime does unnecessary range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1252429216.54.0.0299762545487.issue6823@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +patch

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

From report at bugs.python.org  Tue Sep  8 21:10:42 2009
From: report at bugs.python.org (caglar10ur)
Date: Tue, 08 Sep 2009 19:10:42 +0000
Subject: [issue6865] Refcount error in pwd module
In-Reply-To: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za>
Message-ID: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za>


New submission from caglar10ur <caglar at pardus.org.tr>:

Fix refcounting problem which causes a segfault for following test code;

--------------------------------------------------------
#include <python2.5/Python.h>

int main(void)
{
    int i;
    for (i = 0; i < 1000; ++i)
    {
        Py_Initialize();
        PyRun_SimpleString("import pwd\n");
        Py_Finalize();
    }
    return 0;
}
--------------------------------------------------------

Reported-by: Onur K???k <onur at pardus.org.tr>
Signed-off-by: S.?a?lar Onur <caglar at pardus.org.tr>

----------
files: pwdmodule_refcount_fix.patch
keywords: patch
messages: 92425
nosy: caglar10ur
severity: normal
status: open
title: Refcount error in pwd module
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file14863/pwdmodule_refcount_fix.patch

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

From report at bugs.python.org  Tue Sep  8 21:24:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Sep 2009 19:24:43 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1252437883.77.0.0122329052384.issue6795@psf.upfronthosting.co.za>


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

Fixed in r74719 (release26-maint), r74720 (release31-maint).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Sep  8 22:03:50 2009
From: report at bugs.python.org (Mark Roddy)
Date: Tue, 08 Sep 2009 20:03:50 +0000
Subject: [issue6866] TestLoader.loadTestsFromName does not use suiteClass
	attribute to create TestSuite instances
In-Reply-To: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>
Message-ID: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>


New submission from Mark Roddy <markroddy at gmail.com>:

The TestLoader class in unittest.py has an attribute 'suiteClass' that 
is used to create instances of TestSuite object(s) in the process of 
loading tests.  If it is desired to subclass the TestSuite class then 
consumers may set this attribute on a TestLoader object in order to 
override what TestSuite class gets instantiated (a pythonic version of 
the factory method pattern).  

However, the loadTestsFromName() on the TestLoader class does not use 
this attribute to create TestSuite instances, and instead has a hard 
coded reference to the unittest.TestSuite class.  This results in the 
base class being created instead of a possibly desired subclass that 
has been specified via this attribute.  

Solution for this issue is to change the loadTestsFromName() method to 
use the suiteClass attribute when creating TestSuite objects instead 
using a reference to the TestSuite class.  Included is a patch that 
implements this behavior as well as two additional test for the 
test_unittest.py file which expose this issue if run against an 
unpatched version of unittest.

----------
components: Library (Lib)
files: unittest.patch
keywords: patch
messages: 92427
nosy: MarkRoddy
severity: normal
status: open
title: TestLoader.loadTestsFromName does not use suiteClass attribute to create TestSuite instances
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14864/unittest.patch

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

From report at bugs.python.org  Tue Sep  8 22:06:21 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 08 Sep 2009 20:06:21 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1252440381.82.0.814348498497.issue6071@psf.upfronthosting.co.za>


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

Can't hurt :)

----------
nosy: +georg.brandl
priority: high -> release blocker

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

From report at bugs.python.org  Tue Sep  8 22:22:23 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Sep 2009 20:22:23 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252441343.29.0.351085083194.issue6163@psf.upfronthosting.co.za>


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

> compiler.find("gcc") >= 0 or compiler.find("g++") >= 0

Why not `("gcc" in compiler or "g++" in compiler)`? Just curious.

----------

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

From report at bugs.python.org  Tue Sep  8 22:25:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Sep 2009 20:25:01 +0000
Subject: [issue6866] TestLoader.loadTestsFromName does not use suiteClass
	attribute to create TestSuite instances
In-Reply-To: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>
Message-ID: <1252441501.82.0.475273457078.issue6866@psf.upfronthosting.co.za>


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

I haven't run the tests, but a quick glance at the code makes me think
this is still probably an issue in 2.7/3.1.

----------
assignee:  -> michael.foord
nosy: +michael.foord, r.david.murray
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Tue Sep  8 22:25:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Sep 2009 20:25:57 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252441557.79.0.864359411096.issue6857@psf.upfronthosting.co.za>


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

I've changed the default alignment for Decimal instances to right-aligned 
(so that it agrees with floats and ints) in r74723 (trunk), r74725 (py3k),
as agreed in the python-dev thread starting at:
http://mail.python.org/pipermail/python-dev/2009-September/091640.html

----------

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

From report at bugs.python.org  Tue Sep  8 22:31:50 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 08 Sep 2009 20:31:50 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252441910.74.0.306076373173.issue6857@psf.upfronthosting.co.za>


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

Thanks for the decimal work, Mark. I notice that complex is also left
aligned, by default. I'll take a look at that.

----------

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

From report at bugs.python.org  Tue Sep  8 23:27:50 2009
From: report at bugs.python.org (Mark Roddy)
Date: Tue, 08 Sep 2009 21:27:50 +0000
Subject: [issue6866] TestLoader.loadTestsFromName does not use suiteClass
	attribute to create TestSuite instances
In-Reply-To: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>
Message-ID: <1252445270.45.0.593773301503.issue6866@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

The issue appears to be in the other versions mentioned from manual 
inspection.

Also adding another patch as unittest in the trunk has been broken 
apart into a package with several modules so the original patch will 
not work there.

----------
Added file: http://bugs.python.org/file14865/unittest.trunk.patch

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

From report at bugs.python.org  Tue Sep  8 23:59:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Sep 2009 21:59:24 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1252447164.33.0.165378987998.issue6822@psf.upfronthosting.co.za>


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

Oh yes, FTP.storlines() fails if the file is a text file. Here is a
patch. My patch encodes each line with self.encoding, which is latin1 by
default.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file14866/ftplib.patch

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

From report at bugs.python.org  Wed Sep  9 00:23:23 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Sep 2009 22:23:23 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1252448603.38.0.977911684899.issue6822@psf.upfronthosting.co.za>


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

Does this still pass the test suite? in test_ftplib, storlines() is given 
a BytesIO object.

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

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

From report at bugs.python.org  Wed Sep  9 00:48:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Sep 2009 22:48:10 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1252450090.74.0.354428916671.issue6822@psf.upfronthosting.co.za>


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

@amaury.forgeotdarc: Oops, no, it doesn't.

The new patch includes a new test (for the unicode file).

----------
Added file: http://bugs.python.org/file14867/ftplib-2.patch

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

From report at bugs.python.org  Wed Sep  9 00:48:17 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Sep 2009 22:48:17 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1252450097.02.0.861721968918.issue6822@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14866/ftplib.patch

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

From report at bugs.python.org  Wed Sep  9 01:04:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Sep 2009 23:04:40 +0000
Subject: [issue6865] Refcount error in pwd module
In-Reply-To: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za>
Message-ID: <1252451080.58.0.281960416658.issue6865@psf.upfronthosting.co.za>


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

Fixed in r74727.

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

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

From report at bugs.python.org  Wed Sep  9 03:40:23 2009
From: report at bugs.python.org (Tim Peters)
Date: Wed, 09 Sep 2009 01:40:23 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252460423.23.0.809522684675.issue6836@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Right, I /was/ hallucinating about serialno -- good catch.

Mysterious little integers still suck, though ;-)  If you're going to
store it in a byte, then you can #define semi-meaningful letter codes
instead; e.g.,

#define _PYMALLOC_OBJECT_ID 'o'
#define _PYMALLOC_MEM_ID 'm'

The place where those are defined would be a good place to document what
the heck they mean too.

----------

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

From report at bugs.python.org  Wed Sep  9 03:57:14 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 09 Sep 2009 01:57:14 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252461434.52.0.692503689942.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Can I add a field to the PyBaseExceptionObject struct?

----------

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

From report at bugs.python.org  Wed Sep  9 03:58:00 2009
From: report at bugs.python.org (shaowei.cui)
Date: Wed, 09 Sep 2009 01:58:00 +0000
Subject: [issue6867] return value of epoll.register
In-Reply-To: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za>
Message-ID: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za>


New submission from shaowei.cui <shaovie at gmail.com>:

help(select.epoll) show 'register(fd[, eventmask]) -> bool', but it
return 'None' actually. 

I view the source code of selectmodule.c that return None actually.

The function "pyepoll_internal_ctl(int epfd, int op, PyObject *pfd,
unsigned int events)"

----------
assignee: georg.brandl
components: Documentation
messages: 92440
nosy: georg.brandl, shaovie
severity: normal
status: open
title: return value of epoll.register
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Sep  9 04:13:11 2009
From: report at bugs.python.org (shaowei.cui)
Date: Wed, 09 Sep 2009 02:13:11 +0000
Subject: [issue6868] Check errno of epoll_ctrl
In-Reply-To: <1252462391.45.0.469283463386.issue6868@psf.upfronthosting.co.za>
Message-ID: <1252462391.45.0.469283463386.issue6868@psf.upfronthosting.co.za>


New submission from shaowei.cui <shaovie at gmail.com>:

in selectmodule.c, I found the code of epoll module
'        result = epoll_ctl(epfd, op, fd, &ev);
        if (errno == EBADF) {
            /* fd already closed */
            result = 0;
            errno = 0;
        }
'
'man epoll_ctl' show 'EBADF  epfd or fd is not a valid file
descriptor.', assume I register an fd of 'open('xxx', O_RDONLY)', return
value will be -1, errno will be EBADF,  
epoll not support 'file descriptors.' as i know,  or i register an fd
was not be opened.

----------
components: Library (Lib)
messages: 92441
nosy: shaovie
severity: normal
status: open
title: Check errno of epoll_ctrl
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Sep  9 04:18:46 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Sep 2009 02:18:46 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252462726.1.0.181058172631.issue6844@psf.upfronthosting.co.za>


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

I had a feeling you were going to ask that. =) I think it's fine, and from 
what I can tell from PEP 384 it's okay as long as it is in no way publicly 
exposed. But I have added Martin to the nosy list to make sure I am not 
messing up the ABI somehow in a micro release.

----------
assignee:  -> loewis
nosy: +loewis

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

From report at bugs.python.org  Wed Sep  9 07:26:07 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 09 Sep 2009 05:26:07 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252473967.05.0.0805406385221.issue6163@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

> > compiler.find("gcc") >= 0 or compiler.find("g++") >= 0

> Why not `("gcc" in compiler or "g++" in compiler)`? Just curious.

Fine with me too.

----------

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

From report at bugs.python.org  Wed Sep  9 10:31:15 2009
From: report at bugs.python.org (Ilya)
Date: Wed, 09 Sep 2009 08:31:15 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>


New submission from Ilya <kaplan.ilya at gmail.com>:

When embedding python from C, and importing "ctypes" module in embedded 
script, it always crashes on Py_Finalize() on 4th cycle.
Tested with both PyRun_SimpleString(...) and PyRun_String(...).
Platform: Windows XP
IDE's: LabWindows/CVI 8.5 and Code::Blocks/gcc

Code:
--------------------------
#include <stdio.h>
#include <python.h>

int main()
{
    int i;
    for (i=0; i<10; i++)
    {
        printf("--- %d ---\n", i);
        Py_Initialize();
        PyRun_SimpleString("import ctypes");
        Py_Finalize();
    }
    return 0;
}
--------------------------------
Output:
--------------------------------
--- 0 ---
--- 1 ---
--- 2 ---
--- 3 ---

Process returned -1073741819 (0xC0000005)   execution time : 3.109 s
Press any key to continue.
--------------------------------

----------
assignee: theller
components: ctypes
messages: 92444
nosy: Warlock, theller
severity: normal
status: open
title: Embedded python crashed on 4th run, if "ctypes" is used
type: crash
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Sep  9 11:06:23 2009
From: report at bugs.python.org (Pravin Chavan)
Date: Wed, 09 Sep 2009 09:06:23 +0000
Subject: [issue6870] sybase module for python3.1
In-Reply-To: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za>
Message-ID: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za>


New submission from Pravin Chavan <pravinpchavan at rediffmail.com>:

How can I use sybase module in python 3.1?

----------
components: Extension Modules
messages: 92445
nosy: pravinpchavan
severity: normal
status: open
title: sybase module for python3.1
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Wed Sep  9 11:09:52 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 09 Sep 2009 09:09:52 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252487392.0.0.761277944955.issue6163@psf.upfronthosting.co.za>


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

done in r74728 (trunk), r74729 (2.6.x), r74730 (pyk3) and r74731 (3.1.x)


Thanks guys !

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

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

From report at bugs.python.org  Wed Sep  9 12:13:23 2009
From: report at bugs.python.org (caglar10ur)
Date: Wed, 09 Sep 2009 10:13:23 +0000
Subject: [issue6865] Refcount error in pwd module
In-Reply-To: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za>
Message-ID: <1252491203.59.0.209557699838.issue6865@psf.upfronthosting.co.za>


caglar10ur <caglar at pardus.org.tr> added the comment:

It seems Python 2.6.x also have same problem, will it be merged 
automatically (seems like svn-merge is used for this purpose) or do you 
want me to open a new bug against that version?

----------

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

From report at bugs.python.org  Wed Sep  9 12:28:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 09 Sep 2009 10:28:46 +0000
Subject: [issue6870] sybase module for python3.1
In-Reply-To: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za>
Message-ID: <1252492126.88.0.698916656405.issue6870@psf.upfronthosting.co.za>


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

This question is off-topic for the Python bug tracker. Please use a 
different forum, such as comp.lang.python (aka: python-list at python.org)

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

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

From report at bugs.python.org  Wed Sep  9 13:50:42 2009
From: report at bugs.python.org (Emlyn Murphy)
Date: Wed, 09 Sep 2009 11:50:42 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1252497042.45.0.32920204991.issue6851@psf.upfronthosting.co.za>


Changes by Emlyn Murphy <me at emlyn.net>:


----------
nosy: +emlyn

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

From report at bugs.python.org  Wed Sep  9 14:49:58 2009
From: report at bugs.python.org (Ilya)
Date: Wed, 09 Sep 2009 12:49:58 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1252500598.96.0.0447132338764.issue6869@psf.upfronthosting.co.za>


Ilya <kaplan.ilya at gmail.com> added the comment:

Tested
   obj=PyImport_ImportModule("ctypes");
   Py_DECREF(obj);
instead of PyRun_SimpleString(...) - same result

----------

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

From report at bugs.python.org  Wed Sep  9 15:30:03 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 09 Sep 2009 13:30:03 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252503003.16.0.343114661315.issue6163@psf.upfronthosting.co.za>


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

>From http://svn.python.org/view/python/trunk/Misc/NEWS?
r1=74728&r2=74727&pathrev=74728

  "Initial patch by Sridhar Ratnakumar"

The author of the initial patch - distutils_hpux_libdir_option.patch - 
is actually Trent Mick. I only pulled it from the ActivePython patches/ 
directory and reported it here. I must have mentioned this before; and 
I will do so from now.

----------

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

From report at bugs.python.org  Wed Sep  9 15:42:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 09 Sep 2009 13:42:37 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1252503757.91.0.801635581829.issue6163@psf.upfronthosting.co.za>


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

The rule I apply is as follow (any other rule would be too complicated
for me): 

I add in Misc/NEWS the name of the user that initialy provides the patch
in the tracker.

If you want a different name, you need to provide a patch with the text
you want to see in Misc/NEWS included.

----------

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

From report at bugs.python.org  Wed Sep  9 16:21:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Sep 2009 14:21:00 +0000
Subject: [issue6865] Refcount error in pwd module
In-Reply-To: <1252491203.59.0.209557699838.issue6865@psf.upfronthosting.co.za>
Message-ID: <1afaf6160909090720x11f57b34y1e04bc4480243fc7@mail.gmail.com>


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

2009/9/9 caglar10ur <report at bugs.python.org>:
>
> caglar10ur <caglar at pardus.org.tr> added the comment:
>
> It seems Python 2.6.x also have same problem, will it be merged
> automatically (seems like svn-merge is used for this purpose) or do you
> want me to open a new bug against that version?

It's now backported.

----------

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

From report at bugs.python.org  Wed Sep  9 18:07:22 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Sep 2009 16:07:22 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

I've two more issues where format behavior should probably be identical:

1: (version 2.6 vs. 3.1):

Version 2.6:
>>> format(Decimal("NaN"), "+08.4")
'+0000NaN'
>>> format(float("NaN"), "+08.4")
'+00.0nan'

Version 3.1:
>>> format(Decimal("NaN"), "+08.4")
'+NaN    '
>>> format(float("NaN"), "+08.4")
'+0000nan'


2: (float vs. decimal):

>>> format(float(123), "00")
'123.0'
>>> format(Decimal(123), "00")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/decimal.py", line 3611, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.1/decimal.py", line 5563, in
_parse_format_specifier
    raise ValueError("Invalid format specifier: " + format_spec)
ValueError: Invalid format specifier: 00

----------
messages: 92453
nosy: marketdickinson, skrah
severity: normal
status: open
title: decimal.py: more format issues

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

From report at bugs.python.org  Wed Sep  9 18:22:02 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Sep 2009 16:22:02 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252513322.59.0.150403547862.issue6844@psf.upfronthosting.co.za>


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

Making this a release blocker to see what Barry thinks of this.

----------
priority:  -> release blocker

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

From report at bugs.python.org  Wed Sep  9 19:04:05 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 09 Sep 2009 17:04:05 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252515845.52.0.142476983852.issue6871@psf.upfronthosting.co.za>


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

For #1 for floats, 2.6 is in error. This has been fixed in 2.7 (trunk).

For #2, I think float is correct. The PEP says the specifier is:
[[fill]align][sign][#][0][minimumwidth][.precision][type]
so '00' is parsed as minimumwidth=0 with zero-padding specified.

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

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

From report at bugs.python.org  Wed Sep  9 19:18:19 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Sep 2009 17:18:19 +0000
Subject: [issue1590864] Function-level import in os triggering an threaded
	import deadlock
Message-ID: <1252516699.02.0.619656862687.issue1590864@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/issue1590864>
_______________________________________

From report at bugs.python.org  Wed Sep  9 20:18:39 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 09 Sep 2009 18:18:39 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252520319.06.0.554606396303.issue6871@psf.upfronthosting.co.za>


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

Also, see issue 4482 for a discussion of float formatting for nan and inf.

----------

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

From report at bugs.python.org  Wed Sep  9 21:03:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 19:03:28 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>


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

The readline library supplied in OS X 10.6 looks good enough to use in 
Python.  It would be nice to enable building with this library, to avoid 
having to install GNU readline.

There's a curious off-by-one difference between Apple's readline (which, 
as I understand it, is just libedit wrapped to look like libreadline) 
and GNU readline:  with 'n' history items, the valid indices for Apple's 
readline are 0 through n-1;  for GNU they're 1 through n.

I was able to get Python trunk + system readline working on OS X 10.6 
using the attached patch (which obviously isn't suitable for applying, 
since it breaks the build with a non-system readline).  A side effect of 
the patch is that readline.get_history_item and friends store the first 
history entry with index 0 rather than 1:

Python 2.7a0 (trunk:74735M, Sep  9 2009, 19:40:25) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
[39474 refs]
>>> readline.get_history_item(0)
'import readline'
[39476 refs]
>>> readline.get_history_item(2)
'readline.get_history_item(2)'
[39476 refs]

Interestingly, the Apple-supplied Python also behaves this way:

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_history_item(0)
'import readline'
>>> readline.get_history_item(2)
'readline.get_history_item(2)'

If people think this is worth pursuing, I'll put together a proper 
patch.

----------
assignee: ronaldoussoren
components: Build, Extension Modules, Macintosh
messages: 92457
nosy: marketdickinson, ronaldoussoren
severity: normal
status: open
title: Support system readline on OS X 10.6
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Sep  9 21:04:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 19:04:23 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252523063.14.0.812228801178.issue6872@psf.upfronthosting.co.za>


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

And here's the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file14868/snow_leopard_readline.patch

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

From report at bugs.python.org  Wed Sep  9 21:09:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 19:09:28 +0000
Subject: [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1252523368.42.0.781021874582.issue6786@psf.upfronthosting.co.za>


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

I'd guess the same.  Most of the readline module is just a thin wrapper 
around the system readline library, so if the system readline library uses 
one-based indexing, so does the readline module.  Changing this would 
probably be quite error-prone,  with a high chance of introducing off-by-
one errors somewhere along the line.

Interestingly, the Apple-supplied python (2.6.1) in OS X 10.6 does have 
zero-based readline history.  See issue 6872.

----------
nosy: +marketdickinson

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

From report at bugs.python.org  Wed Sep  9 21:18:13 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 09 Sep 2009 19:18:13 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252523893.2.0.253561086957.issue6872@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I wouldn't mind having a proper patch and doing away with the need for 
GNU's readline.

IMHO the patch should try to stay as close to GNU readline's interface 
as possible, and should therefore fix the off-by-one difference you 
mention.

BTW. I suppose the configuration (readline.parse_and_bind) needs to be 
in libedit format rather than readline format. If so, we should add 
something to the readline documentation about that and possibly add 
something to the readline library to make it possible to detect if 
readline is ultimately linked to libedit.

BTW. If you want to push the Apple's readline to the limit you should 
try if it works properly with ipython. It used to cause hard crashes 
with Apple's python in 10.5.

----------

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

From report at bugs.python.org  Wed Sep  9 21:25:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 19:25:21 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252524321.55.0.725741306888.issue6871@psf.upfronthosting.co.za>


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

Issue #1: In both trunk and py3k I get:

>>> from decimal import Decimal
>>> format(Decimal('nan'), '+08.4')
'    +NaN'
>>> format(float('nan'), '+08.4')
'+0000nan'
>>> format(Decimal('inf'), '+012.4')
'   +Infinity'
>>> format(float('inf'), '+012.4')
'+00000000inf'

Two potential issues here:  first is the zero padding; to me, a zero-
padded nan or inf just looks ugly, but if people think that's the 
correct output (and I suppose that I have to admit that it probably is) 
then I'll add the zeros in for the Decimal type.

The second issue is the difference in spelling; ('nan' versus 'NaN', 
'inf' versus 'Infinity');  I'm not really bothered by this difference, 
and it would be quite awkward to change.  The output format for Decimal 
is mandated by the standard, while changing the spelling for floats 
seems both unnecessary and likely to break code.

Issue #2: This is a bit odd.  If a minimumwidth of 0 is permissible, 
then the format '0' is ambiguous.  Assuming that '0' continues to mean 
zero-padded, this leaves '00' as the *only* way to specify a minimum 
width of 0.  It seems cleaner just to assume that minimumwidth always 
has to be strictly positive, making '00' invalid.  At least, I think 
that's what I was thinking when I wrote the Decimal formatting code.
But I agree that float and Decimal should be consistent here.

----------

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

From report at bugs.python.org  Wed Sep  9 21:34:50 2009
From: report at bugs.python.org (Gawain Bolton)
Date: Wed, 09 Sep 2009 19:34:50 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252524890.2.0.75659820982.issue6713@psf.upfronthosting.co.za>


Gawain Bolton <gp.bolton at computer.org> added the comment:

Yes I agree it would be a good idea to have one definition and one
instantiation of the _decimal_digit_table[] and BitLengthTable[32] arrays.

Where do you suggest these tables could be put?  I'll be happy to
provide an updated patch if you can let me know.

----------

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

From report at bugs.python.org  Wed Sep  9 21:51:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 09 Sep 2009 19:51:33 +0000
Subject: [issue4773] HTTPMessage not documented and has inconsistent API
	across 2.6/3.0
In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za>
Message-ID: <1252525893.43.0.592595962844.issue4773@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Wed Sep  9 21:55:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 19:55:48 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252526148.29.0.326382102681.issue6872@psf.upfronthosting.co.za>


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

Hmm.  This is looking like a bigger task than I bargained for.  I notice 
that the readline library currently has no tests (or maybe I'm just 
failing to find them).  I'm not even sure how to go about writing tests 
for readline.

> IMHO the patch should try to stay as close to GNU readline's interface 
> as possible, and should therefore fix the off-by-one difference you 
> mention.

I suppose so.  I'm a bit worried about subtle bugs occurring as a result 
of fixing off-by-one differences in some places and missing them in 
others;  it seems safer to provide direct access to the library behaviour 
without trying to fix anything.  Third-party stuff that wants to work with 
Apple's Python is also going to have to deal with zero-based history.  So 
I guess I'd prefer not to fix the off-by-one difference;  this would make 
it even more important to provide some way for users to tell whether 
they're using GNU readline or the wrapped libedit version.

Thanks for the ipython suggestion;  I've never used it before, but I'll 
see if I can play around with it a bit.

----------

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

From report at bugs.python.org  Wed Sep  9 21:59:31 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Sep 2009 19:59:31 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252526371.55.0.110206394122.issue6713@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  9 22:47:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 20:47:56 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252529276.15.0.162199154591.issue6713@psf.upfronthosting.co.za>


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

I'm a bit ambivalent about this patch:  I'd like to see string to integer 
conversions improved, and on the surface it makes sense to special-case 
base 10 conversions (just as power-of-two bases are already special-
cased), but this seems like quite a lot of extra code to debug and 
maintain just to speed up one aspect of the integer implementation.  It 
would be easy to grow longobject.c by several thousand lines by adding a 
handful of optimizations of this type.

If you're working with huge integers and care about speed, then you should 
probably be using gmpy or similar (or something other than Python).  And 
this patch doesn't solve the real problem with converting huge integers to 
and from decimal strings, which is that the algorithms used have quadratic 
running time.  Amongst quadratic-time algorithms, I'm tempted to call 
Python's implementation 'good enough'.

Gawain, do you have a particular use-case in mind for this optimization?  
Are there common applications where string <-> int conversion times are 
critical?

----------
versions: +Python 3.2

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

From report at bugs.python.org  Wed Sep  9 23:01:23 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 09 Sep 2009 21:01:23 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>


New submission from Boya Sun <boya.sun at case.edu>:

posix_lchown(PyObject *self, PyObject *args)
{
        ...
 	int uid, gid;
        ...
 	if (!PyArg_ParseTuple(args, "etii:lchown",
 	                      Py_FileSystemDefaultEncoding, &path,
 	                      &uid, &gid))
        ...
}

uid and gid could cause over flow. A similar bug is issue 5705.

Patch attached.  Any comment is appreciated!

Boya

----------
files: patch.diff
keywords: patch
messages: 92465
nosy: boya
severity: normal
status: open
title: posix_lchown: possible overflow of uid, gid
Added file: http://bugs.python.org/file14869/patch.diff

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

From report at bugs.python.org  Wed Sep  9 23:05:56 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 09 Sep 2009 21:05:56 +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: <1252530356.07.0.443211159251.issue5705@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Created issue 6879 following Victor's suggestion.

----------

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

From report at bugs.python.org  Wed Sep  9 23:06:26 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Sep 2009 21:06:26 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252530386.92.0.937372192715.issue6871@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Issue 1:

I would definitely keep the spelling in decimal, my concern was only the
padding.

The C standard agrees with Mark's view:

"Leading zeros (following any indication of sign or base) are used to
pad to the field width rather than performing space padding, except when
converting an infinity or NaN."

If this could be agreed on, issue 1 should be handled by changing float
and decimal 2.6.


Issue 2:

I can't find it quickly in the C standard, but gcc warns in this situation:

   warning: repeated '0' flag in format

This would support the behavior of decimal and float should be changed.


I would like to add two new issues.

Issue 3:

Regarding padding, the C standard further says:

"If the 0 and - flags both appear, the 0 flag is ignored"

This is quite sensible, since signless 0 padding looks a bit awkward.
(But this is a minor issue). 


Issue 4:

>>> format(Decimal('1e88'), '0<20')
'1E+88000000000000000'

>>> format(float('1e88'), '0<20')
'0000000000000001e+88'

I think right-padding with digits is dangerous, since it changes the
numerical value. I'm not sure what float does, it doesn't look correct
(but protects the user).

----------

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

From report at bugs.python.org  Wed Sep  9 23:07:31 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 09 Sep 2009 21:07:31 +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: <1252530451.61.0.0821313446719.issue5705@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Sorry, typo.

Created issue 6873 following Victor's suggestion.

----------

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

From report at bugs.python.org  Wed Sep  9 23:11:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 21:11:06 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252530666.72.0.313065295051.issue6713@psf.upfronthosting.co.za>


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

On the other hand, _PyLong_Format currently contains general machinery 
for integer -> string conversion in any base in the range [2, 36], but I 
don't think that machinery is ever used for bases other than 2, 8, 10 
and 16.  So ripping _PyLong_Format out and just leaving the binary base 
and the suggested base 10 code might actually make longobject.c shorter.

I'd be interested to know how much the conversion of two digits at one 
time instead of one is contributing to the speedup by itself.  For large 
integers, I'd suspect that this makes very little difference.

----------

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

From report at bugs.python.org  Thu Sep 10 00:05:27 2009
From: report at bugs.python.org (loveminix)
Date: Wed, 09 Sep 2009 22:05:27 +0000
Subject: [issue6854] UnicodeDecodeError when retrieving binary data from
	cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1252533927.09.0.475817094106.issue6854@psf.upfronthosting.co.za>


loveminix <loveminix at yahoo.com.cn> added the comment:

Is there an update on this? Let me know if more information is needed.

----------

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

From report at bugs.python.org  Thu Sep 10 08:46:24 2009
From: report at bugs.python.org (s7v7nislands)
Date: Thu, 10 Sep 2009 06:46:24 +0000
Subject: [issue6874] sequence method .count() and .index() shoud be in
	immutable sequence method list.
In-Reply-To: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za>
Message-ID: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za>


New submission from s7v7nislands <s7v7nislands at gmail.com>:

In document 6.6.4. Mutable Sequence Types says:
The following operations are defined on mutable sequence types:
s.count(x) 	return number of i?s for which s[i] == x 	 
s.index(x[, i[, j]]) 	return smallest k such that s[k] == x and i <= k
< j 	(4)

here, s.count() and s.index() maybe should in immutable sequence types
operations list.

----------
assignee: georg.brandl
components: Documentation
messages: 92471
nosy: georg.brandl, s7v7nislands
severity: normal
status: open
title: sequence method  .count() and .index() shoud be in immutable sequence method list.

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

From report at bugs.python.org  Thu Sep 10 09:48:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Sep 2009 07:48:42 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252568922.5.0.179955751627.issue6713@psf.upfronthosting.co.za>


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

> If you're working with huge integers and care about speed, then 
> you should probably be using gmpy or similar

I disagree with you, mark. The patch is around 20 lines and does optimize all
cases, not only the "huge integers". See my benchmark: conversion for small
integers (type 'int') are also faster (7 to 22%). I think that the base 10 is more
common than 2^k bases, and a conversion from integer to decimal string is a
very common operation in Python.

----------

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

From report at bugs.python.org  Thu Sep 10 10:02:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Sep 2009 08:02:21 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252569741.81.0.470078901075.issue6873@psf.upfronthosting.co.za>


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

posix modules contains a lot of function parsing uid_t / gid_t types. I would be
nice to factorize the code: create a function to get an uid_t, and another to
get a gid_t. I don't know the name of such callback, but it's used with:
PyArg_ParseTuple(args, "...O&...", ..., &uid, get_uid, ...)).

Such callbacks will be useful for: posix_chown(), posix_fchown(),
posix_lchown(), posix_setuid(), posix_seteuid(), posix_setreuid(),
posix_setegid(), posix_setregid(), posix_setgid().

And maybe also in: posix_setgroups().

In Python trunk, posix_set*id() function do check for uid_t/gid_d overflow, but
not the posix_*chown() functions. The patch only fixes posix_lchown().

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

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

From report at bugs.python.org  Thu Sep 10 10:05:49 2009
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Sep 2009 08:05:49 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252569949.95.0.310579011426.issue6871@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Issue 3 is nonsense, '-' means left-justified in C. Sorry.

----------

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

From report at bugs.python.org  Thu Sep 10 10:57:51 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 10 Sep 2009 08:57:51 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252573071.77.0.870763725867.issue6872@psf.upfronthosting.co.za>


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

I also agree that this is desirable to have, and that the readline module 
should provide the GNU semantics even with a different implementation.

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

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

From report at bugs.python.org  Thu Sep 10 11:03:25 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 10 Sep 2009 09:03:25 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252573405.03.0.794294146738.issue6873@psf.upfronthosting.co.za>


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

The patch is incorrect. Why do you think there is an overflow? There is 
none in the call to ParseTuple: the i argument parser expects a signed 
int*; passing a long* will break on systems where 
sizeof(int)!=sizeof(long) (such as typical 64-bit Unix).

In addition, the *actual* overflow in the current code (casting to uid_t) 
is not handled in the patch.

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

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

From report at bugs.python.org  Thu Sep 10 13:47:05 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Thu, 10 Sep 2009 11:47:05 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

As per the blog entry
http://www.logilab.org/blogentry/17873

I think the tempfile.mkstemp() documentation could be more helpful by
suggesting the use of os.close() appropriately.

If some native english speaker could give a review of the language I
used in the additional text, I'd be grateful.

----------
assignee: georg.brandl
components: Documentation
files: python-doc-mkstemp.patch
keywords: patch
messages: 92477
nosy: georg.brandl, vincele
severity: normal
status: open
title: add os.close() suggestion to mkstemp documentation
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file14870/python-doc-mkstemp.patch

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

From report at bugs.python.org  Thu Sep 10 13:49:04 2009
From: report at bugs.python.org (Stefan Schwarzburg)
Date: Thu, 10 Sep 2009 11:49:04 +0000
Subject: [issue6876] readline documentation example error
In-Reply-To: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za>
Message-ID: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za>


New submission from Stefan Schwarzburg <stefan.schwarzburg at googlemail.com>:

In the last example in the readline documentation
(http://docs.python.org/library/readline.html), the line

code.InteractiveConsole.__init__(self)

should be changed to 

code.InteractiveConsole.__init__(self, locals, filename)

to work properly.

----------
assignee: georg.brandl
components: Documentation
messages: 92478
nosy: georg.brandl, schwarz
severity: normal
status: open
title: readline documentation example error
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/issue6876>
_______________________________________

From report at bugs.python.org  Thu Sep 10 13:49:12 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Thu, 10 Sep 2009 11:49:12 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1252583352.43.0.247427597003.issue6875@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Or a review of the markup I used

----------

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

From report at bugs.python.org  Thu Sep 10 14:38:29 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 12:38:29 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>


New submission from Zvezdan Petkovic <zvezdan at zope.com>:

The attached patch enables compilation and use of the readline module on 
Mac OS X 10.5 (Leopard) and 10.6 (Snow Leopard).
It utilizes the native editline library (used for emulation of the 
readline library on Mac).

I used the patch for almost two years already with Python 2.4 and since 
December 2008 with Python 2.6.  The only difference is that Python 2.4 
did not need the setup.py changes.

The patch is written in such a way that it does *not* affect the 
compilation on systems that use GNU readline library (e.g., Linux).
However, I don't have access to any other system that uses editline 
emulation of readline library besides Mac.  I believe it should work the 
same but some testing would be welcome if anyone is aware of such a 
system (NetBSD?).

With the readline module compiled in, it is enough to put in .editrc

    python:bind -v

and one gets a vi emulation in the python interactive interpreter.

You can also try it directly from the shell:

    >>> import readline
    >>> readline.parse_and_bind("bind -v")
    >>> # use editing features to change the lines above to
    >>> import rlcompleter
    >>> readline.parse_and_bind("bind ^I rl_complete")
    >>> # now TAB offers the completions

It would be nice if we could get this included into Python-2.6.3 
release.

----------
components: Build
files: readline-trunk.patch
keywords: patch
messages: 92480
nosy: zvezdan
severity: normal
status: open
title: enable compilation of readline module on Mac OS X 10.5 and 10.6
type: compile error
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/file14871/readline-trunk.patch

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

From report at bugs.python.org  Thu Sep 10 14:44:54 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 12:44:54 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1252586694.25.0.859910242942.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Changed type to "crash" because compilation of readline module without 
this patch was causing Python to crash with BusError.

----------
type: compile error -> crash

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

From report at bugs.python.org  Thu Sep 10 14:50:27 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 12:50:27 +0000
Subject: [issue4204] Cannot build _multiprocessing, math,
	mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
In-Reply-To: <1224957663.27.0.455052730171.issue4204@psf.upfronthosting.co.za>
Message-ID: <1252587027.79.0.995091903286.issue4204@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

I worked around the issue mentioned in msg82619.
The readline patch (issue 6877) is not adversely affected by the patch 
applied in this issue.  This issue can remain closed AFAIC.

----------

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

From report at bugs.python.org  Thu Sep 10 15:02:46 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 13:02:46 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1252587766.28.0.808979985112.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

When testing the patch make sure that your readline module has been 
actually linked against editline library rather then some copy of GNU 
readline from MacPorts or Fink.

Assuming --prefix=${HOME}/opt, the output of

    otool -L ~/opt/lib/python2.4/lib-dynload/readline.so

should contain /usr/lib/libedit.2.dylib.

----------

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

From report at bugs.python.org  Thu Sep 10 15:20:37 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 10 Sep 2009 13:20:37 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252588837.48.0.480554117334.issue6247@psf.upfronthosting.co.za>


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

This was rejected prior to Steven Bethard becoming involved, so I'm
reopening.

+1 from me - argparse is a great module to use.

----------
nosy: +michael.foord
resolution: rejected -> 
status: closed -> open

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

From report at bugs.python.org  Thu Sep 10 15:37:06 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 13:37:06 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252589826.38.0.253519262966.issue6872@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

This patch could potentially break non-Mac OS X systems.
Fortunately, I have a patch that works with systems that use GNU 
readline and systems that use editline emulation. See issue 6877.

Unfortunately, I was lingering for over a year with opening a tracker 
issue for it.  Last night I did the last testing session with the trunk 
checkout and I did not notice that this issue has been opened in the 
meantime.

Sorry for opening the double issue.
I think that the patch from issue 6877 should be used.

----------
nosy: +zvezdan

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

From report at bugs.python.org  Thu Sep 10 15:43:09 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 13:43:09 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252590189.82.0.642630956714.issue6872@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Also, the patch from issue 6877 changes setup.py in a way that enables 
build of the readline module on Leopard as well.

Such build is used for about two years already (Python 2.4) by several 
people in my company and nobody noticed any issues on Mac OS X Leopard.
AFAICT, it works the same now on Snow Leopard.

----------

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

From report at bugs.python.org  Thu Sep 10 15:50:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Sep 2009 13:50:49 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1252590649.85.0.0670347668571.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm +1 on merging this functionality.

See also: issue6872

As I mentioned there we should ensure that readline linked to libedit 
has the same semantics as readline linked to GNU readline, and because 
the configuration file of libedit has a different format as the one of 
readline we should mention that in the documentation as well.

It would also be nice if one could programmaticly detect if readline is 
linked to libedit, that way tools like ipython can load the right 
configuration files without user interaction.


BTW. I'm pretty sure that the readline emultation on Leopard was pretty 
broken, ipython used to cause hard crashes with /usr/bin/python on 
Leopard.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Thu Sep 10 16:16:53 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 10 Sep 2009 14:16:53 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252592213.53.0.995567257434.issue6872@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/issue6872>
_______________________________________

From report at bugs.python.org  Thu Sep 10 16:20:54 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 10 Sep 2009 14:20:54 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252592454.08.0.130043182744.issue6713@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I ran this patch against Unladen Swallow's slowspitfire template 
benchmark, which does more int->string conversions than any of our other 
benchmarks. When run against Python trunk r74737, I get these results:

slowspitfire:
Min: 0.888772 -> 0.867427: 2.46% faster
Avg: 0.891857 -> 0.872461: 2.22% faster
Significant (t=45.532127, a=0.95)

(./perf.py -r -b slowspitfire ../a/python.exe ../b/python.exe)
This was an idle MacBook Pro, OS X 10.5.8, Apple gcc 4.0.1, 2.4 GHz Core 
Duo.

Other benchmarks benefit, but are only barely statistically significant.

----------

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

From report at bugs.python.org  Thu Sep 10 16:35:41 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 14:35:41 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1252593341.13.0.687083716584.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

> It would also be nice if one could programmaticly detect if readline
> is linked to libedit

There's this rl_library_version constant defined in editline/readline C 
libraries that the attached patch uses.
Perhaps, if we can expose its value from the Python readline module, one 
could check whether the value startswith("EditLine wrapper") in ipython 
and similar programs.

Regarding your comment about editline being broken on Leopard:  The 
patch worked just fine for me and other people who used it in my 
company.  We used line editing and history in interactive interpreter 
with both Python 2.4 and Python 2.6 on Leopard.

One person used it with Python 2.4 and ipython.  He did not have a 
readline functionality until he compiled with the patch.  After applying 
the patch the line editing, history and TAB completion worked for him in 
ipython.  He's now running Snow Leopard so we couldn't check one more 
time.
 
Perhaps you meant it was broken on Tiger (10.4; Darwin 8).

----------

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

From report at bugs.python.org  Thu Sep 10 17:05:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Sep 2009 15:05:50 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252595150.91.0.101379673777.issue6713@psf.upfronthosting.co.za>


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

Thanks for those results, Collin.

> By benchmark should be reproduced on a 64 bits CPU with 2^15 and 2^30
> bases for the long type.

On OS X 10.6 (64-bit Python non-debug non-framework build with gcc 4.2 
from Apple, 30-bit long digits, straight ./configure && make), Victor's 
benchmark gives me the following results:

original = 1023.9 ms  (best of 10 runs)
patched = 1005.3 ms (best of 10 runs).

- a speedup of about 1.85%.  So it looks as though x86_64 doesn't benefit 
to the same extent that 32-bit does.  Presumably that's because gcc-4.2 is 
unable or unwilling to turn a 64-bit by 64-bit division with a constant 
dividend of 10**9 into a multiplication;  I don't know whether using a 
later gcc would make a difference.

----------

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

From report at bugs.python.org  Thu Sep 10 18:39:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Sep 2009 16:39:47 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252600787.04.0.544143537442.issue6713@psf.upfronthosting.co.za>


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

Sorry:  ignore that last message;  I was talking through my hat.  I 
think I must have been unwittingly building in debug mode.

Ahem.  After a 'make distclean', I get the following results (same specs 
as above, on a 2.53Ghz MacBook Pro / Core 2 Duo).

original: 783.8 ms
patched:  373.5 ms  (2.1 x faster)
patch 2:  323.7 ms  (2.4 x faster)

patch 2 (attached) is Gawain's original patch, but with the base != 
2,8,10,16 code removed and the call to _inplace_divrem1 inlined and 
slightly reorganized.  (No changes to intobject.c.)

----------
Added file: http://bugs.python.org/file14872/base10_conversion_performance_patch2.txt

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

From report at bugs.python.org  Thu Sep 10 18:41:05 2009
From: report at bugs.python.org (James)
Date: Thu, 10 Sep 2009 16:41:05 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252600865.87.0.806256748761.issue6872@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

it seems to me, that any and all readline interfaces should/could
standardize to the indexing scheme as used by the language; maybe i'm
wrong, but since python is zero based, so could the readline interfaces.

it's definitely more logical for a python programmer to expect
zero-based, and the code will match with the python code.

i would propose that everything be zero-based;
this is duplicate/similar of/to http://bugs.python.org/issue6786

----------
nosy: +purpleidea

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

From report at bugs.python.org  Thu Sep 10 18:42:13 2009
From: report at bugs.python.org (James)
Date: Thu, 10 Sep 2009 16:42:13 +0000
Subject: [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1252600933.1.0.805855396829.issue6786@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

@mark: thanks for the comment; i suppose we should investigate why and
if c readline is 1 based...

----------

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

From report at bugs.python.org  Thu Sep 10 18:47:24 2009
From: report at bugs.python.org (James)
Date: Thu, 10 Sep 2009 16:47:24 +0000
Subject: [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1252601244.65.0.148766266855.issue6786@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

i found this:
http://tiswww.case.edu/php/chet/readline/history.html
search for: "Variable: int history_base"
perhaps we can set this to 0 in the python bindings.
more so, perhaps someone is using 1 because they made a mistake?

----------

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

From report at bugs.python.org  Thu Sep 10 19:25:08 2009
From: report at bugs.python.org (SilentGhost)
Date: Thu, 10 Sep 2009 17:25:08 +0000
Subject: [issue6878] outdated docstring in tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

Doc string for tkinter/__init__.py Canvas.coords (line 2115 in
python3.1.1) reads: """Return a list of coordinates for the item given
in ARGS."""

actual code: return map(...etc...)

I actually don't know whether it's an outdated docstring, may be coords
should return a tuple.

----------
components: Tkinter
messages: 92495
nosy: SilentGhost
severity: normal
status: open
title: outdated docstring in tkinter.Canvas.coords
versions: Python 3.1

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

From report at bugs.python.org  Thu Sep 10 19:39:57 2009
From: report at bugs.python.org (Boya Sun)
Date: Thu, 10 Sep 2009 17:39:57 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252604397.41.0.611145254173.issue6873@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Martin,

The reason why I think there is a possible overflow is that according to
issue 5705, uid/gid overflows are fixed in the following functions:
posix_setegid, posix_setreuid(), posix_setregid(), posix_setgid(). So I
think a similar fix should also be applied to the function posix_lchown.
Or did I misunderstand anything?

And you're right. The previous patch is incorrect. I now submitted
another patch that deals with the *actual* overflow of gid and uid. 

---
Victor,

I agree that all posix_*chown() functions should also be fixed for the
same overflow problem, and it's a good idea to create callback functions
as you described. But if nobody does that, I can at least created more
patches to fix other posix_*chown() functions.

----------
Added file: http://bugs.python.org/file14873/patch_6873.diff

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

From report at bugs.python.org  Thu Sep 10 19:40:02 2009
From: report at bugs.python.org (Boya Sun)
Date: Thu, 10 Sep 2009 17:40:02 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252604402.61.0.601008049968.issue6873@psf.upfronthosting.co.za>


Changes by Boya Sun <boya.sun at case.edu>:


Removed file: http://bugs.python.org/file14869/patch.diff

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

From report at bugs.python.org  Thu Sep 10 20:02:03 2009
From: report at bugs.python.org (Boya Sun)
Date: Thu, 10 Sep 2009 18:02:03 +0000
Subject: [issue6817] char buffer in function posix_getcwdu should not be fix
	length
In-Reply-To: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>
Message-ID: <1252605723.47.0.801172577791.issue6817@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Victor,

I corrected both issues of the patch according to your first comment. 

This patch did not fix the Windows implementation. It seems that there
will not be buffer overflow in the Windows implementation, since if the
buffer is small for GetCurrentDirectoryW(), the code allocates a new
buffer for it with enough length by the following code:

        len = GetCurrentDirectoryW(sizeof wbuf/ sizeof wbuf[0], wbuf);
	if (len >= sizeof wbuf/ sizeof wbuf[0]) {
		wbuf2 = malloc(len * sizeof(wchar_t));
		if (wbuf2)
			len = GetCurrentDirectoryW(len, wbuf2);
	}

----------
Added file: http://bugs.python.org/file14874/patch_6817.diff

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

From report at bugs.python.org  Thu Sep 10 22:10:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Sep 2009 20:10:45 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252613445.67.0.443854204749.issue6713@psf.upfronthosting.co.za>


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

One more iteration of the patch is attached: I rewrote the conversion
algorithm to do the base PyLong_BASE to base 10**e conversion first,
then output the base 10**e array as individual digits.  For OS
X/Intel, this seems to speed things up significantly.

(First three values below are the same as before.)

OS X 10.6, 64-bit build of Python, 30-bit digits:

original: 783.8 ms
patch 1:  373.5 ms  (2.1 x faster)
patch 2:  323.7 ms  (2.4 x faster)
patch 3:  250.1 ms  (3.1 x faster)

For OS X 10.5, 32-bit build of Python with 15-bit digits, on the same platform as above, 
I get the following timings:

original: 2045.1 ms
patch 1 : 1052.2 ms (1.94 x faster)
patch 2 : 1228.7 ms (1.66 x faster)
patch 3 :  725.8 ms (2.82 x faster)

----------
Added file: http://bugs.python.org/file14875/base10_conversion_performance_patch3.txt

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

From report at bugs.python.org  Fri Sep 11 00:40:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Sep 2009 22:40:25 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252622425.01.0.956301974576.issue6713@psf.upfronthosting.co.za>


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

I don't understand the following comment in patch3:
/* convert: base 2 in pin -> base 10 in pout */

I  think that pin base is 2^30 / 2^15 and pout base is 10^9 / 10 ^ 4, not 10.

----------

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

From report at bugs.python.org  Fri Sep 11 01:26:05 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 10 Sep 2009 23:26:05 +0000
Subject: [issue2848] Remove mimetools usage from the stdlib
In-Reply-To: <1210726775.09.0.0627957766628.issue2848@psf.upfronthosting.co.za>
Message-ID: <1252625165.77.0.177635885769.issue2848@psf.upfronthosting.co.za>


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


----------
nosy: +Merwok

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

From report at bugs.python.org  Fri Sep 11 01:47:04 2009
From: report at bugs.python.org (Sandip Thorat)
Date: Thu, 10 Sep 2009 23:47:04 +0000
Subject: [issue6617] During compiling python 3.1 getting error Undefined
	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1252626424.91.0.187383822983.issue6617@psf.upfronthosting.co.za>


Sandip Thorat <thoratsandip at gmail.com> added the comment:

Which file do i edit to add LDFLAGS=-lintl  ?

and at what place?

----------

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

From report at bugs.python.org  Fri Sep 11 02:44:00 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Sep 2009 00:44:00 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1252629840.65.0.970199240847.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file14860/smime.p7s

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

From report at bugs.python.org  Fri Sep 11 03:35:46 2009
From: report at bugs.python.org (Gene Ratzlaff)
Date: Fri, 11 Sep 2009 01:35:46 +0000
Subject: [issue6879] misstatement in example explanation using raise
In-Reply-To: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>
Message-ID: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>


New submission from Gene Ratzlaff <generatz at gmail.com>:

v2.6.2 Python Tutorial
http://docs.python.org/tutorial/errors.html#raising-exceptions
Section 8. Errors and Exceptions
8.4. Raising Exceptions

It appears that in the example, the original may have been:
raise(NameError('HiThere')) and was then changed to
raise NameError('HiThere') but the explanation was not changed
accordingly.  The current state and my suggested change are found below,
respectively:

Currently:
"""
>>> raise NameError('HiThere')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: HiThere

The first argument to raise names the exception to be raised. The
optional second argument specifies the exception?s argument.
Alternatively, the above could be written as
raise NameError('HiThere'). Either form works fine, but there seems to
be a growing stylistic preference for the latter.
"""

Suggest change to:
"""
>>> raise NameError('HiThere')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: HiThere

The first argument to raise names the exception to be raised. The
optional second argument specifies the exception?s argument.
Alternatively, the above could be written as
raise(NameError('HiThere')). Either form works fine, but there seems to
be a growing stylistic preference for the former.
"""

----------
assignee: georg.brandl
components: Documentation
messages: 92501
nosy: bluebloodpole, georg.brandl
severity: normal
status: open
title: misstatement in example explanation using raise
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep 11 03:46:15 2009
From: report at bugs.python.org (Gene Ratzlaff)
Date: Fri, 11 Sep 2009 01:46:15 +0000
Subject: [issue6880] class needs forward reference
In-Reply-To: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za>
Message-ID: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za>


New submission from Gene Ratzlaff <generatz at gmail.com>:

http://docs.python.org/tutorial/errors.html#user-defined-exceptions

class mechanism used in 8.5 before classes are explained in chapter 9. 
Suggest first use of word "class" be a forward link to "9. Classes":
http://docs.python.org/tutorial/classes.html#classes

----------
assignee: georg.brandl
components: Documentation
messages: 92502
nosy: bluebloodpole, georg.brandl
severity: normal
status: open
title: class needs forward reference
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep 11 04:41:50 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Fri, 11 Sep 2009 02:41:50 +0000
Subject: [issue6845] ftplib rest support for storbinary
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1252636910.92.0.527899794366.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


Removed file: http://bugs.python.org/file14841/issue6845.patch

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

From report at bugs.python.org  Fri Sep 11 04:43:50 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Fri, 11 Sep 2009 02:43:50 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1252637030.35.0.584105303233.issue6845@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

I'm changing the title to something clearer (I hope).
The patch I submitted adds the retr optional parameter to the storbinary
method.

----------
title: ftplib rest support for storbinary -> Restart support in binary upload for ftplib
Added file: http://bugs.python.org/file14876/issue6845.patch

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

From report at bugs.python.org  Fri Sep 11 09:54:17 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 11 Sep 2009 07:54:17 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252655657.76.0.0903817516389.issue6873@psf.upfronthosting.co.za>


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

I think the new patch is still incorrect. You now pass long variables into 
the i argument parser. Also, I would expect that compilers prefer to see 
an explicit cast from long to uid_t, in case it's a truncating cast.

Can you try your patch on a system where all this is an actual problem?

----------

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

From report at bugs.python.org  Fri Sep 11 10:05:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Sep 2009 08:05:56 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252656356.17.0.100662207304.issue6873@psf.upfronthosting.co.za>


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

@loewis: I don't think that the explicit cast is required. posix_setuid() has no
explicit cast. But I would also prefer an explicit cast (just for the readability).

----------

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

From report at bugs.python.org  Fri Sep 11 11:24:44 2009
From: report at bugs.python.org (egreen)
Date: Fri, 11 Sep 2009 09:24:44 +0000
Subject: [issue6881] incorrect signature in doc for PyByteArray_Resize
In-Reply-To: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>
Message-ID: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>


New submission from egreen <egreen at operamail.com>:

in Doc/c-api/bytearray.rst:

    PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)

should be:

    int PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)

as per Include/bytearrayobject.h

----------
assignee: georg.brandl
components: Documentation
messages: 92506
nosy: egreen, georg.brandl
severity: normal
status: open
title: incorrect signature in doc for PyByteArray_Resize
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Sep 11 11:59:13 2009
From: report at bugs.python.org (Dirk Haage)
Date: Fri, 11 Sep 2009 09:59:13 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>


New submission from Dirk Haage <haage at net.in.tum.de>:

a simple import uuid will always result in a zombie sh process:

$ python3
Python 3.1.1 (r311:74480, Aug 19 2009, 16:23:08) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import uuid
>>> 

13528 pts/5    Ss     0:01  \_ bash
18349 pts/5    S+     0:00  |   \_ python3
18352 pts/5    Z+     0:00  |       \_ [sh] <defunct>

confirmed on ubuntu and gentoo with various python3.0 - 3.1.1 builds

----------
messages: 92507
nosy: dhg
severity: normal
status: open
title: uuid creates zombies
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Sep 11 11:59:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Sep 2009 09:59:37 +0000
Subject: [issue6617] During compiling python 3.1 getting error Undefined
	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1252663177.7.0.958211770187.issue6617@psf.upfronthosting.co.za>


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

I'm not a Unix expert at all, but did you try to export the variable?
    export LDFLAGS=-lintl
then "configure" and "make".

----------

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

From report at bugs.python.org  Fri Sep 11 16:04:06 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Sep 2009 14:04:06 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1252677846.61.0.173350911184.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Just when I was starting to feel comfortable using Hg, this happens. It
appears that between my inexperience with Hg and the non-intuitive
TortoiseHg rebase merge tool, many of the changes I made to
posixmodule.c were lost and as amaury.forgeotdarc remarked, other
commits were reverted.

This means that except for the patches in this ticket, I've lost the
revision history for this work. No biggie.

I've rebuilt the patch from scratch (still against the old code base).
I'm including it here for posterity as draft 8. I'll be attempting once
again to rebase it against the parent's tip. Stay tuned.

----------
Added file: http://bugs.python.org/file14877/windows symlink draft 8.patch

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

From report at bugs.python.org  Fri Sep 11 16:26:28 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 11 Sep 2009 14:26:28 +0000
Subject: [issue6883] OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
Message-ID: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>


New submission from Skip Montanaro <skip at pobox.com>:

The OptionParser.allow_interspersed_args attribute is undocumented in
the Sphinx documentation.  (It is mentioned in the OptionParser
docstring.)  By its name it appears to actually part of the official
API, so should at least be mentioned in the rst file.

----------
messages: 92510
nosy: skip.montanaro
severity: normal
status: open
title: OptionParser.allow_interspersed_args is undocumented

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

From report at bugs.python.org  Fri Sep 11 16:28:29 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 11 Sep 2009 14:28:29 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

With a simple setup.py:

from distutils.core import setup
setup(name='packagename')

And a MANIFEST.in containing:

include buildout.cfg 

The result of a debug run of python setup.py sdist on Windows is:

Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'sdist' command:
  {}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
warning: sdist: missing required meta-data: version, url
warning: sdist: missing meta-data: either (author and author_email) or 
(maintainer and maintainer_email) mus
t be supplied
checking if setup.py newer than MANIFEST
warning: sdist: standard file not found: should have one of README, 
README.txt
reading manifest template 'MANIFEST.in'
include buildout.cfg
include_pattern: applying regex r'^buildout\.cfg$'
 adding buildout.cfg
Distribution.get_command_obj(): creating 'build' command object
exclude_pattern: applying regex r'^build\.*'
 removing buildout.cfg

...

The regex built is incorrect, although it is apparently correctly built 
on other platforms...

----------
assignee: tarek
messages: 92511
nosy: cjw296, tarek
priority: normal
severity: normal
stage: test needed
status: open
title: Impossible to include file in sdist that starts with 'build' on Win32
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Sep 11 18:03:04 2009
From: report at bugs.python.org (Boya Sun)
Date: Fri, 11 Sep 2009 16:03:04 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252684984.93.0.530397781877.issue6873@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Martin,

I am sorry that I do not have a system where this code actually
triggered a problem, since this bug is discovered by a *static* analysis
tool that is recently developed by our research group, which finds code
segments that are similar to a previously fixed bugs as potential bugs.
 You are saying that if I pass a long to the i argument parser it will
cause a problem. But if I passed a int, it will be same as before and
overflow will not be detected at all.  

---
Victor,

Do you also agree that it will cause a problem if I pass a long to the i
argument parser? If so, I think maybe the overflow problem cannot be
solved by the patch I submitted.

Boya

----------

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

From report at bugs.python.org  Fri Sep 11 19:39:59 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Sep 2009 17:39:59 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1252690799.45.0.773077924369.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After only a few hours of fighting with Hg and gnashing of teeth, I've
merged the patch with the head of the SVN py3k branch.  I'm attaching
this as draft 9. This patch was created with Subversion and should be
suitable for easy merging.

I've compiled and tested the patched code and the three tests in
test_win_symlink.py all pass.

Please let me know if there's anything more I can do to help move this
forward.

----------
Added file: http://bugs.python.org/file14878/windows symlink draft 9.patch

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

From report at bugs.python.org  Fri Sep 11 19:49:37 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Fri, 11 Sep 2009 17:49:37 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252691377.26.0.438031395414.issue6882@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Actually it's a bug in ctypes.util.find_library() which is called from
uuid.py. The function doesn't close() popen object leaving forked
process in zombie state. I attach the fix.

----------
keywords: +patch
nosy: +marcin.bachry
Added file: http://bugs.python.org/file14879/find_library_popen.diff

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

From report at bugs.python.org  Fri Sep 11 20:45:56 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 18:45:56 +0000
Subject: [issue6885] pdb documentation shows running as script using "python"
	not "python3"
In-Reply-To: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>
Message-ID: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>


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

The library documentation page for pdb shows running pdb as a script
using the command
        python -m pdb
Shouldn't that be
        python3 -m pdb
?

----------
assignee: georg.brandl
components: Documentation
messages: 92515
nosy: MLModel, georg.brandl
severity: normal
status: open
title: pdb documentation shows running as script using "python" not "python3"
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 11 20:57:18 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Sep 2009 18:57:18 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252695438.7.0.140732907268.issue6839@psf.upfronthosting.co.za>


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

In the case at issue, the file name is the same (contrary to the error
message). The two representations of the *path* are different, but
equivalent. There is no ambiguity: the file should be put in directory
'test' and named 'test2.txt'. So I think zipfile should do what 7zip
does and do just that.

An actual filename difference might be argued differently.

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

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

From report at bugs.python.org  Fri Sep 11 21:01:57 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 19:01:57 +0000
Subject: [issue6886] cgi.py runs python, not python3
In-Reply-To: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za>
Message-ID: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za>


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

The file cgi.py in the lib directory is an executable beginning with the
line:

#! /usr/local/bin/python

Shouldn't that be python3?

----------
components: Library (Lib)
messages: 92517
nosy: MLModel
severity: normal
status: open
title: cgi.py runs python, not python3
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 11 21:04:36 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 19:04:36 +0000
Subject: [issue6887] executables in lib use /usr/bin/env python, not python3
In-Reply-To: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>
Message-ID: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>


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

Some of the executables in lib begin with the line:

#! /usr/bin/env python

Shouldn't that be python3?

----------
components: Library (Lib)
messages: 92518
nosy: MLModel
severity: normal
status: open
title: executables in lib use /usr/bin/env python, not python3
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 11 21:08:36 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Sep 2009 19:08:36 +0000
Subject: [issue6887] executables in lib use /usr/bin/env python, not python3
In-Reply-To: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>
Message-ID: <1252696116.8.0.229506482351.issue6887@psf.upfronthosting.co.za>


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

Honestly those lines should probably be stripped out and simply expect 
people to use runpy to execute the modules.

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

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

From report at bugs.python.org  Fri Sep 11 21:08:52 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Sep 2009 19:08:52 +0000
Subject: [issue6887] executables in lib use /usr/bin/env python, not python3
In-Reply-To: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>
Message-ID: <1252696132.09.0.450482568059.issue6887@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> low
type:  -> behavior

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

From report at bugs.python.org  Fri Sep 11 21:41:10 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Sep 2009 19:41:10 +0000
Subject: [issue6854] UnicodeDecodeError when retrieving binary data from
	cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1252698070.41.0.390474108973.issue6854@psf.upfronthosting.co.za>


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

0. When you have a problem, and you are not sure it is an error in the
interpreter or stdlib, try posting to python-list first. If you do not
soon get a definitive determination here, do that. This is not a
question-answering or user-code debugging list.

1. When posting code so others can read it, please leave off trailing
semi-colons. Python is not C. The unnecessary ';'s are distracting noise.

2. When posting problematic code, please strip it down to the minimum
necessary to show the problem. From what I understand, the minimum here is
"import cgi; d = cgi.FieldStorage()". The rest is distracting noise. 

3. When you get a error traceback, copy and paste *the whole traceback*
(especially when requested).

4. Post the exact interpreter version used.  Is this with 3.1.1, with
all the latest bug fixes? Even better, try with the lastest version and
say so.

5. When the problem involved interacting with the external system (such
as os.environ), specify the os. It often makes a difference.

In this case, your problem seems to be that the relevant field of
os.environ has a non-ascii char. My impression is that this is not
intented to be allowed, at least for posix systems, but I am not sure.
It is possible that something in the module has not been updated
properly, but I do not know enough of the specs to say whether the
problem is your data or the library code.

You should determine the 'offending' string and print out its
representation (with repr(s)) and include that with any further post
here or on python-list. In general, include offending data (also
minimized) along with offending code.

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

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

From report at bugs.python.org  Fri Sep 11 21:52:03 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Sep 2009 19:52:03 +0000
Subject: [issue6874] sequence method .count() and .index() shoud be in
	immutable sequence method list.
In-Reply-To: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za>
Message-ID: <1252698723.89.0.901241318344.issue6874@psf.upfronthosting.co.za>


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

This is covered in point 4 of open issue #4966

----------
nosy: +tjreedy
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Fri Sep 11 22:21:15 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 20:21:15 +0000
Subject: [issue6888] pdb alias command with no arguments is broken
In-Reply-To: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za>
Message-ID: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za>


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

Typing just 
    alias
in pdb doesn't work. Because dict.keys() now returns a dict_keys object
instead of a list the line
    keys.sort()
in Pdb.do_alias breaks because dict_keys doesn't have a sort method.

----------
components: Library (Lib)
messages: 92522
nosy: MLModel
severity: normal
status: open
title: pdb alias command with no arguments is broken
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 11 22:34:10 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Sep 2009 20:34:10 +0000
Subject: =?utf-8?q?=5Bissue6889=5D_=C2=ABPython=E2=80=99s_default_encoding_is_the_?=
	=?utf-8?b?4oCYYXNjaWnigJkgZW5jb2Rpbmcuwrs=?=
In-Reply-To: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za>
Message-ID: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

In the Python ?Unicode HOWTO?, we still read the statement:

?For example, Python's default encoding is the 'ascii'
encoding.?

Here:
http://svn.python.org/view/python/branches/py3k/Doc/howto/unicode.rst?revision=72294&view=markup

----------
assignee: georg.brandl
components: Documentation
messages: 92523
nosy: flox, georg.brandl
severity: normal
status: open
title: ?Python?s default encoding is the ?ascii? encoding.?
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 11 22:42:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Sep 2009 20:42:49 +0000
Subject: =?utf-8?q?=5Bissue6889=5D_=C2=ABPython=E2=80=99s_default_encoding_is_the_?=
	=?utf-8?b?4oCYYXNjaWnigJkgZW5jb2Rpbmcuwrs=?=
In-Reply-To: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za>
Message-ID: <1252701769.62.0.390068210723.issue6889@psf.upfronthosting.co.za>


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

Fixed in r74740.

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

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

From report at bugs.python.org  Fri Sep 11 22:50:44 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 11 Sep 2009 20:50:44 +0000
Subject: [issue6890] IOError has no __unicode__ method - and loses information
In-Reply-To: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za>
Message-ID: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za>


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

>>> try:
...  open('flooble')
... except Exception as e:
...  pass
... 
[39343 refs]
>>> str(e)
"[Errno 2] No such file or directory: 'flooble'"
[39345 refs]
>>> unicode(e)
u"(2, 'No such file or directory')"

The Unicode representation of an IOError has no information about the
file or directory name. This is a regression from 2.5. Would be nice to
backport a fix to 2.6 if we can.

This bit docutils - and can happen as a side-effect of interpolating
into a Unicode string with %s. The filename information is lost from the
error report.

----------
components: IO
keywords: 26backport
messages: 92525
nosy: michael.foord
severity: normal
status: open
title: IOError has no __unicode__ method - and loses information
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Sep 11 23:01:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Sep 2009 21:01:53 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1252702913.91.0.992644484822.issue6839@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 11 23:03:31 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Sep 2009 21:03:31 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252703011.18.0.111028287349.issue6882@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 11 23:15:50 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Sep 2009 21:15:50 +0000
Subject: =?utf-8?b?W2lzc3VlNjg5MV0gc21hbGwgdHlwbyBpbiDCq3VuaWNvZGUucnN0wrs6IMKr?=
	=?utf-8?q?the_Uniode_APIs_should_be_used=C2=BB_and_broken_URL?=
In-Reply-To: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>
Message-ID: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

Found 2 typos:
 - Uniode instead of Unicode
 - Acknowledgements instead of Acknowledgments

And the following reference is broken (Jason Orendorff website):
http://www.jorendorff.com/articles/unicode/

The last version is dated 2007 on the wayback machine:
http://web.archive.org/web/*/www.jorendorff.com/articles/unicode/index.html

Relevant file is:
Doc/howto/unicode.rst

----------
assignee: georg.brandl
components: Documentation
messages: 92526
nosy: flox, georg.brandl
severity: normal
status: open
title: small typo in ?unicode.rst?: ?the Uniode APIs should be used? and broken URL
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 11 23:17:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Sep 2009 21:17:26 +0000
Subject: [issue6888] pdb alias command with no arguments is broken
In-Reply-To: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za>
Message-ID: <1252703846.5.0.122681990204.issue6888@psf.upfronthosting.co.za>


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

Fixed in r74741.

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

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

From report at bugs.python.org  Sat Sep 12 00:06:34 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Sep 2009 22:06:34 +0000
Subject: [issue6890] IOError has no __unicode__ method - and loses information
In-Reply-To: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za>
Message-ID: <1252706794.68.0.382046490161.issue6890@psf.upfronthosting.co.za>


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

If your curious, this is the bug report that broke it:
http://bugs.python.org/issue2517

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

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

From report at bugs.python.org  Sat Sep 12 00:19:49 2009
From: report at bugs.python.org (Dirk Haage)
Date: Fri, 11 Sep 2009 22:19:49 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252707589.07.0.526464257647.issue6882@psf.upfronthosting.co.za>


Dirk Haage <haage at net.in.tum.de> added the comment:

this patch solves it for me.

----------

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

From report at bugs.python.org  Sat Sep 12 04:13:01 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 12 Sep 2009 02:13:01 +0000
Subject: [issue6892] optparser example in optparse documentation is broken
In-Reply-To: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za>
Message-ID: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za>


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

The help example in the middle of the optparse library documentation is
broken. The code reads:

parser = OptionParser()
parser.add_option("-h", "--help", action="help"),
parser.add_option("-v", action="store_true", dest="verbose",
                  help="Be moderately verbose")
parser.add_option("--file", dest="filename",
                  help="Input file to read data from"),

The result of executing this code is:

optparse.OptionConflictError: option -h/--help: conflicting option
string(s): -h, --help

I see that the documentation says that normally help is added
automatically so you don't need to do it, but doing so shouldn't break
especially since the example shows doing it.

Also, the trailing commas on two of the lines are weird and should be
removed.

----------
assignee: georg.brandl
components: Documentation
messages: 92530
nosy: MLModel, georg.brandl
severity: normal
status: open
title: optparser example in optparse documentation is broken
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep 12 04:18:12 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 12 Sep 2009 02:18:12 +0000
Subject: [issue6892] optparser example in optparse documentation is broken
In-Reply-To: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za>
Message-ID: <1252721892.88.0.0267954136083.issue6892@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

There are other places on the same page with weird trailing commas that
should be removed. I think they all follow right parentheses.

----------

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

From report at bugs.python.org  Sat Sep 12 04:33:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 02:33:19 +0000
Subject: =?utf-8?b?W2lzc3VlNjg5MV0gc21hbGwgdHlwbyBpbiDCq3VuaWNvZGUucnN0wrs6IMKr?=
	=?utf-8?q?the_Uniode_APIs_should_be_used=C2=BB_and_broken_URL?=
In-Reply-To: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>
Message-ID: <1252722799.38.0.88137310975.issue6891@psf.upfronthosting.co.za>


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

These typos are present in py3k but not in the trunk. I searched for the
commit on the trunk to see if other things had been fixed and not merged
on py3k but I couldn't find it.

----------
nosy: +ezio.melotti
priority:  -> low

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

From report at bugs.python.org  Sat Sep 12 04:46:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Sep 2009 02:46:54 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1252723614.44.0.401597502969.issue6875@psf.upfronthosting.co.za>


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

I don't think it would be beneficial to just talk about closing the file
descriptor, or to talk about os open file limits.  Closing open files
when they are no longer needed is just good programming practice and IMO
a discussion of it doesn't belong in the library docs unless it is at a
more generic level (like os.open or open).

I don't think the code shown in your blog post is using the library the
way it is designed.  If the programmer wants an open file object, they
should use TemporaryFile or NamedTemporaryFile.  If there really is a
reason to get an os file handle and turn it into a file object, then
os.openfd should be used.  Perhaps the appropriate change to the
documentation would be to mention os.openfd, and to mention that
os.close is the correct function to use to close the file handle when it
is no longer needed (unless, of course, openfd has been called).

As for your markup, your ``os.close`` should instead be
:func:`os.close`, which results in the automatic creation of a link to
the os.close documentation.

----------
nosy: +r.david.murray
priority:  -> normal
versions: +Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Sep 12 05:03:43 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 03:03:43 +0000
Subject: [issue6893] defaultdict example in py3 doc should mention the new
	Counter class
In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
Message-ID: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>


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

The 3rd example of defaultdict [1] shows how to use it to count the
letters of a string, but the new Counter class is a better tool for
doing that.

Possible solutions:
1) "Setting the default_factory to int makes the defaultdict useful for
counting (like a bag or multiset in other languages):" -> "Setting the
default_factory to int makes the defaultdict useful for basic counting
(see also the Counter class for more features):";
2) remove the example.

[1]:
http://docs.python.org/dev/py3k/library/collections.html#defaultdict-examples

----------
assignee: georg.brandl
components: Documentation
messages: 92534
nosy: ezio.melotti, georg.brandl, rhettinger
priority: low
severity: normal
status: open
title: defaultdict example in py3 doc should mention the new Counter class
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep 12 05:13:47 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 12 Sep 2009 03:13:47 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252725227.9.0.862247675061.issue6247@psf.upfronthosting.co.za>


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

Only +0 purely because I haven't used argparse myself yet.

Otherwise I would probably be +1, since I have several scripts that have
fairly kludgy hacked together optparse based approaches to handling
positional arguments, subparsers and building new parsers that accept
the superset of options defined in existing parsers. The feature
comparison between argparse and optparse makes it sound like argparse
does a much better job of supporting these use cases.

The reasons I don't use argparse for them are that: a) I didn't know it
existed until recently; and b) the scripts are in an environment where
getting approval to use new third party modules is something of a pain.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Sat Sep 12 05:15:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Sep 2009 03:15:51 +0000
Subject: =?utf-8?b?W2lzc3VlNjg5MV0gc21hbGwgdHlwbyBpbiDCq3VuaWNvZGUucnN0wrs6IMKr?=
	=?utf-8?q?the_Uniode_APIs_should_be_used=C2=BB_and_broken_URL?=
In-Reply-To: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>
Message-ID: <1252725351.58.0.271284723966.issue6891@psf.upfronthosting.co.za>


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

The sentence containing the Uniode typo didn't exist when the howtos
were imported on trunk.  That sentence was added to the py3k docs by
r67338.  Fixed in r74749.

The Acknowledgements spelling exists on trunk.  But apparently both
spellings are acceptable, so I'm not bothering to fix that one.

I defer to Georg about the link.

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

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

From report at bugs.python.org  Sat Sep 12 10:09:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Sep 2009 08:09:45 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252742985.6.0.363607663565.issue6713@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/issue6713>
_______________________________________

From report at bugs.python.org  Sat Sep 12 10:45:38 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 12 Sep 2009 08:45:38 +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: <1252745138.37.0.623922512443.issue6108@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/issue6108>
_______________________________________

From report at bugs.python.org  Sat Sep 12 11:22:24 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 12 Sep 2009 09:22:24 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1252747344.66.0.411311289938.issue6875@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

The real question I had is why mkstemp return an os-level opened file
descriptor instead of a python file object...

----------

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

From report at bugs.python.org  Sat Sep 12 12:12:29 2009
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Barrois?=)
Date: Sat, 12 Sep 2009 10:12:29 +0000
Subject: [issue6894] urllib2 doesn't respect "no_proxy" environment
	(python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>


New submission from Rapha?l Barrois <xelnor_python at melix.net>:

I discovered recently that urllib2 doesn't respect the "no_proxy" 
environment variable on linux (and on other platforms too, I think).

Here is an example of the problem :
- Set http_proxy and no_proxy environment variables (for instance 
no_proxy="localhost")

proxy_handler = urllib2.ProxyHandler()
opener = urllib2.build_opener(proxy_handler)
urllib2.install_opener(opener)

and then open an "outside" url : everything is OK (urllib2 reads 
correctly http_proxy), but for "localhost", it tries to open it 
through the proxy.

You would expect urllib2 to understand no_proxy, all the more since 
all the needed code is already available in urllib.

I have prepared a patch for urllib2 which does correct that bug.

I don't have other versions of python installed, so I couldn't check 
that se bug is still present there.

----------
components: Library (Lib)
files: python2.6.2-urllib2-no_proxy.patch
keywords: patch
messages: 92538
nosy: xelnor
severity: normal
status: open
title: urllib2 doesn't respect "no_proxy" environment  (python2.6.2)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14880/python2.6.2-urllib2-no_proxy.patch

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

From report at bugs.python.org  Sat Sep 12 12:52:30 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 12 Sep 2009 10:52:30 +0000
Subject: [issue6856] allow setting uid and gid when creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252752750.63.0.665867831628.issue6856@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I applied the patch with some more small fixes to the trunk (r74750) and
the py3k branch (r74751).

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

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

From report at bugs.python.org  Sat Sep 12 13:57:20 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 12 Sep 2009 11:57:20 +0000
Subject: [issue6863] Wrong linker command if CXX set to "ccache g++"
In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
Message-ID: <1252756640.85.0.0527457433117.issue6863@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Aren't CC and CXX variables just for compilers?

"""
CC
    Program for compiling C programs; default `cc'.
CXX
    Program for compiling C++ programs; default `g++'.
"""
http://www.gnu.org/software/make/manual/make.html#index-CXX-848

----------
nosy: +akitada

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

From report at bugs.python.org  Sat Sep 12 14:46:33 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 12 Sep 2009 12:46:33 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1252759593.35.0.221322087973.issue1294959@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I think this is duplicate of issue858809.

----------

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

From report at bugs.python.org  Sat Sep 12 14:46:38 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 12 Sep 2009 12:46:38 +0000
Subject: [issue1019715] distutils ignores configure's --includedir
Message-ID: <1252759598.47.0.454414432234.issue1019715@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I think this is duplicate of issue858809.

----------

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

From report at bugs.python.org  Sat Sep 12 15:10:05 2009
From: report at bugs.python.org (=?utf-8?q?Pertti_Kellom=C3=A4ki?=)
Date: Sat, 12 Sep 2009 13:10:05 +0000
Subject: [issue6863] Wrong linker command if CXX set to "ccache g++"
In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
Message-ID: <1252761005.64.0.487949661326.issue6863@psf.upfronthosting.co.za>


Pertti Kellom?ki <pertti.kellomaki at tut.fi> added the comment:

The linker is usually called via a compiler, which arranges for compiler
specific libraries to be included in the linking. See e.g. section 10.2
in the GNU Make manual:

Linking a single object file

n is made automatically from n.o by running the linker (usually called
ld) via the C compiler. The precise command used is `$(CC) $(LDFLAGS)
n.o $(LOADLIBES) $(LDLIBS)'.

----------

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

From report at bugs.python.org  Sat Sep 12 15:25:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 12 Sep 2009 13:25:32 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252684984.93.0.530397781877.issue6873@psf.upfronthosting.co.za>
Message-ID: <4AABA148.1050408@v.loewis.de>


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

>  You are saying that if I pass a long to the i argument parser it will
> cause a problem. But if I passed a int, it will be same as before and
> overflow will not be detected at all.  

Correct. So you should use the l argument parser.

----------

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

From report at bugs.python.org  Sat Sep 12 16:22:35 2009
From: report at bugs.python.org (=?utf-8?q?Jonas_Bystr=C3=B6m?=)
Date: Sat, 12 Sep 2009 14:22:35 +0000
Subject: [issue6831] 2to3 assignment division conversion
In-Reply-To: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>
Message-ID: <1252765355.56.0.00876137821131.issue6831@psf.upfronthosting.co.za>


Jonas Bystr?m <highfestiva at gmail.com> added the comment:

I would like something like a regexp-replace of

def[ \t]*__idiv__\((.*?)\)

into

def __floordiv__(\1): self.__truediv__(<arg[-1:] goes here>)
def __truediv__(\1)

----------

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

From report at bugs.python.org  Sat Sep 12 16:27:15 2009
From: report at bugs.python.org (Santhosh Thottingal)
Date: Sat, 12 Sep 2009 14:27:15 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>


New submission from Santhosh Thottingal <santhosh.thottingal at gmail.com>:

locale._parse_localename fails when the locale name is in xx_YY format.
For example when the system locale is Malayalam(India),  ml_IN we get
the following result
>>> locale._parse_localename("ml_IN")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python311/lib/python3.1/locale.py", line 424, in
_parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: ml_IN
The expected result is ('ml_IN', None)
For Latin languages, locale.py assumes iso-8859-15 as the encoding type
if encoding type is not given in localename. In case 
of other locales, None can be returned for encoding type.
Attached patch fixes this.
The result after applying patch to locale.py
>>> import locale
>>> locale._parse_localename("ml_IN")
('ml_IN', None)

----------
components: Library (Lib)
files: locale.py-parselocale-patch.diff
keywords: patch
messages: 92546
nosy: santhosh.thottingal
severity: normal
status: open
title: locale._parse_localename fails when localename does not contain encoding information
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14881/locale.py-parselocale-patch.diff

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

From report at bugs.python.org  Sat Sep 12 17:42:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Sep 2009 15:42:26 +0000
Subject: [issue6831] 2to3 assignment division conversion
In-Reply-To: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>
Message-ID: <1252770146.45.0.940627695626.issue6831@psf.upfronthosting.co.za>


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

That would not always be correct because __div__ implements a "default"
division that doesn't exist in Py3k. It's easiest to implement
__floordiv__ and __truediv__ in for 2.x for correct behavior there, too.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sat Sep 12 18:21:14 2009
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=)
Date: Sat, 12 Sep 2009 16:21:14 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1252772474.1.0.892937387078.issue2650@psf.upfronthosting.co.za>


Bj?rn Lindqvist <bjourne at gmail.com> added the comment:

In my app, I need to transform the regexp created from user input so
that it matches unicode characters with their ascii equivalents. For
example, if someone searches for "el nino", that should match the string
"el ?ino". Similarly, searching for "el ?ino" should match "el nino".

The code to transform the regexp looks like this:

s = re.escape(user_input)
s = re.sub(u'n|?', u'[n|?]')
matches = list(re.findall(s, data, re.IGNORECASE|re.UNICODE))

It doesn't work because the ? in the user_input is escaped with a
backslash. My workaround, to compensate for re.escape's to eager
escaping, is to escape re.sub pattern:

s = re.sub(u'\\\\n|\\\\?', u'[\\\\n|\\\\?]')

It works but is not very nice. It would have been much better if
re.escape worked like one could expect in the first place.

----------
nosy: +bjourne

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

From report at bugs.python.org  Sat Sep 12 18:49:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Sep 2009 16:49:44 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1252774184.41.0.024119261368.issue6875@psf.upfronthosting.co.za>


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

Because if you want the Python file object, you should use TemporaryFile
or NamedTemporaryFile.  mkstemp is a lower level (closer to the os)
interface, and is provided because Python has a philosophy of providing
those low level interfaces when possible.  Note that the TemporaryFile
classes use mkstemp in their implementation.

----------

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

From report at bugs.python.org  Sat Sep 12 20:15:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 18:15:14 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>


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

While running test.regrtest, test_mailbox failed with the error:

test test_mailbox failed -- Traceback (most recent call last):
  File "/home/wolf/py3k/Lib/test/test_mailbox.py", line 116, in 
test_discard
    self.assertEqual(len(self._box), 1)
AssertionError: 2 != 1

I ran the test again several times and got intermittent failures in 
several different methods. Attached there's a file with the errors I 
got. 

During the first tests I was running test_mailbox after 
test_zipimport, but then I was able to reproduce the failures running 
test_mailbox alone.

I'm using Python 3.2a0 on Ubuntu 8.04.

----------
components: Tests
files: mailboxfailures.txt
messages: 92550
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: Intermittent failures in test_mailbox
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14882/mailboxfailures.txt

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

From report at bugs.python.org  Sat Sep 12 20:46:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 18:46:52 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils|sqlite) fail if
	zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1252781212.69.0.760888492896.issue6026@psf.upfronthosting.co.za>


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

Fixed in r74754 (trunk) and r74755 (py3k).

----------
keywords:  -needs review, patch
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Sep 12 20:48:46 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 18:48:46 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1252781326.56.0.042216320441.issue6574@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Sep 12 22:05:58 2009
From: report at bugs.python.org (geremy condra)
Date: Sat, 12 Sep 2009 20:05:58 +0000
Subject: [issue6897] imaplib fails during login
In-Reply-To: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za>
Message-ID: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

Getting the following issue- this code:

#! /usr/bin/env python3

import getpass, imaplib

M = imaplib.IMAP4_SSL("imap.gmail.com")
M.login(<username>, <password>)
M.select()
typ, data = M.search(None, 'ALL')
for num in data[0].split():
    typ, data = M.fetch(num, '(RFC822)')
    print('Message %s\n%s\n' % (num, data[0][1]))
M.close()
M.logout()

taken almost verbatim from the documentation, produces this error:

Traceback (most recent call last):
  File "./imaptest.py", line 6, in <module>
    M.login(<username>, <password>)
  File "/usr/lib/python3.0/imaplib.py", line 514, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib/python3.0/imaplib.py", line 1072, in _quote
    arg = arg.replace(b'\\', b'\\\\')
TypeError: Can't convert 'bytes' object to str implicitly

username and password obviously redeacted.

Changing imaplib.py's _quote function to this:

    def _quote(self, arg):

        arg = arg.replace('\\', '\\\\')
        arg = arg.replace('"', '\\"')

        return '"' + arg + '"'

seems to resolve the issue.

----------
components: Library (Lib)
messages: 92552
nosy: debatem1
severity: normal
status: open
title: imaplib fails during login
versions: Python 3.0

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

From report at bugs.python.org  Sat Sep 12 22:12:54 2009
From: report at bugs.python.org (Tom)
Date: Sat, 12 Sep 2009 20:12:54 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1252786374.33.0.260896096109.issue2054@psf.upfronthosting.co.za>


Changes by Tom <tmm at fastmail.fm>:


----------
nosy: +qwavel

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

From report at bugs.python.org  Sat Sep 12 22:44:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Sep 2009 20:44:11 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1252788251.05.0.487048255067.issue6574@psf.upfronthosting.co.za>


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

Accepted, except for two things:

* I'd drop the "a0" suffix for the mandatory version. "2.2" instead of
"2.2.0a0" is much better to comprehend.

* Why the ugly markup with the PEP refs? ``:pep:`number`: blah`` should
work well.

For 3k, all previous future features are still supported, so they can go
in there as well.

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

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

From report at bugs.python.org  Sat Sep 12 23:53:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 21:53:00 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1252792380.24.0.54041809012.issue5511@psf.upfronthosting.co.za>


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

I think there should also be one or more tests that check if the file is
closed correctly after the __exit__, in normal conditions and possibly
in different situations (e.g. when an error is raised ).
Unlike regular file objects, ZipFile objects don't have a 'closed'
attribute, instead they set self.fp to None when the 'close' method is
called.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Sun Sep 13 00:12:03 2009
From: report at bugs.python.org (mkp)
Date: Sat, 12 Sep 2009 22:12:03 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1252793523.0.0.80912778029.issue6869@psf.upfronthosting.co.za>


mkp <mkpmkpmkp9999 at gmail.com> added the comment:

on python2.5 / mac os x 10.5.7:

$ cat main.c
#include <stdio.h>
#include <python.h>

int main()
{
    int i;
    for (i=0; i<10; i++)
    {
        printf("--- %d ---\n", i);
        Py_Initialize();
        PyRun_SimpleString("import ctypes");
        Py_Finalize();
    }
    return 0;
}

$ gcc -I/usr/include/python2.5/ -L/usr/lib/python2.5/ -lpython main.c
$ ./a.out 
--- 0 ---
--- 1 ---
--- 2 ---
--- 3 ---
Assertion failed: (type->tp_flags & Py_TPFLAGS_HEAPTYPE), function 
type_dealloc, file Objects/typeobject.c, line 2148.
Abort trap
$ uname -mprsv
Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; 
root:xnu-1228.12.14~1/RELEASE_I386 i386 i386

----------
nosy: +mkp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6869>
_______________________________________

From report at bugs.python.org  Sun Sep 13 01:30:15 2009
From: report at bugs.python.org (Alan Isaac)
Date: Sat, 12 Sep 2009 23:30:15 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252798215.33.0.0422573858174.issue6844@psf.upfronthosting.co.za>


Alan Isaac <alan.isaac at gmail.com> added the comment:

Since you are working on this, can you see if 
http://bugs.python.org/issue6108 
is related or in any case can be fixed at the same time?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Sun Sep 13 02:57:34 2009
From: report at bugs.python.org (vitvn)
Date: Sun, 13 Sep 2009 00:57:34 +0000
Subject: [issue6898] Unicode  Error
In-Reply-To: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za>
Message-ID: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za>


New submission from vitvn <caothucodon123 at gmail.com>:

>>>viet= "? ? ? ? ? ? ? ? ? ?  ? "

>>>print(viet)


Traceback (most recent call last):
  File "tiengviet.py", line 4, in <module>
    print(viet)
  File "I:\python\python.v3.1_portable\App\lib\encodings\cp1252.py",
line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0103' in
position 2: character maps to <undefined>
>Exit code: 1

how to fix it ?

----------
components: Unicode
messages: 92557
nosy: vitvn
severity: normal
status: open
title: Unicode  Error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6898>
_______________________________________

From report at bugs.python.org  Sun Sep 13 03:02:17 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Sep 2009 01:02:17 +0000
Subject: [issue6898] Unicode  Error
In-Reply-To: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za>
Message-ID: <1252803737.3.0.695524473276.issue6898@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Change your terminal's encoding.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6898>
_______________________________________

From report at bugs.python.org  Sun Sep 13 03:07:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Sep 2009 01:07:32 +0000
Subject: [issue6898] Unicode  Error
In-Reply-To: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za>
Message-ID: <1252804052.38.0.546953158517.issue6898@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It looks like you are using the Windows terminal, that, afaik, is not
able to display the characters you are trying to print. This is because
its default encoding - cp1252 - can encode only a small subset of the
Unicode characters.
If changing the encoding of the terminal doesn't work, you can try to
use a better terminal or IDLE instead.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6898>
_______________________________________

From report at bugs.python.org  Sun Sep 13 03:36:43 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Sep 2009 01:36:43 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1252805803.82.0.784110634053.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I fixed the machine and tried the file that you uploaded, but nothing 
changed. This is what I used (traceback.print_exc() prints to stderr, 
so the traceback should be visible):
$ while ./python Lib/test/regrtest.py -v test_docxmlrpc.py; do :; done 
> /dev/null
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sun Sep 13 07:00:43 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 13 Sep 2009 05:00:43 +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: <1252818043.54.0.726024427778.issue6108@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Perhaps also worth noting is that in Python 2.4 as well, str(exception)
and unicode(exception) returned the same thing.  Unlike some other
exception changes in 2.6, this doesn't seem to be a return to older
behavior, but just a new behavior.  (Or maybe no one cares about that;
just wanted to point it out, though.)

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Sep 13 07:08:04 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 13 Sep 2009 05:08:04 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252818484.69.0.0164459657897.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

FWIW, I'm waiting to hear about the acceptability of adding fields to
the exception structure(s) before I work on this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Sun Sep 13 07:17:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Sep 2009 05:17:00 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252819020.41.0.00163848154066.issue6844@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/issue6844>
_______________________________________

From report at bugs.python.org  Sun Sep 13 10:50:41 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 13 Sep 2009 08:50:41 +0000
Subject: [issue6899] Base.replace breaks tree
In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
Message-ID: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

In Base.replace, the method checks that self.parent is not None - 
however, it (unfortunately), breaks this very property itself if self is 
new, or self in new.

In particular, some fixers return node from transform if they don't want 
to do anything. In that case, self.parent gets set to None, even though 
new (which is self) is still connected to the tree.

This patch
a) short-cuts the case that self is new
b) arranges to set parent of the new nodes only after clearing parent of 
self

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: python.patch
keywords: patch
messages: 92563
nosy: loewis
severity: normal
status: open
title: Base.replace breaks tree
Added file: http://bugs.python.org/file14883/python.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6899>
_______________________________________

From report at bugs.python.org  Sun Sep 13 12:19:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Sep 2009 10:19:14 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252837154.82.0.115565974893.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Barring objections, I plan to apply the 'long_decimal_conversion_py3k' 
patch to the py3k branch; I'll then backport to trunk.  This patch doesn't 
include Gawain's two-decimal-digits-at-a-time optimization;  after I've 
applied the patch, I'll have another look at that.

This would leave the non-binary-base code in _PyLong_Format unused.  I'll 
hold off on removing that code until the python-ideas thread on arbitrary-
base int -> string conversions has reached a conclusion.

----------
keywords: +patch
Added file: http://bugs.python.org/file14884/long_decimal_conversion_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sun Sep 13 12:19:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Sep 2009 10:19:25 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252837165.52.0.1561983468.issue6713@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sun Sep 13 14:06:51 2009
From: report at bugs.python.org (Tom Seddon)
Date: Sun, 13 Sep 2009 12:06:51 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>


New submission from Tom Seddon <bugs.python.org at tomseddon.plus.com>:

Behaviour of "Locate" in latest Windows CHM file for Python 2.6.2 is 
sub-optimal.

I first spotted this with the optparse module, so this bug refers to 
the optparse module. It looks as if this is a global problem, though.

First, ensure one has latest patched Python 2.6.2 CHM file.

Sample repro steps:

- Load Windows CHM file (observe fully collapsed contents tree);

- Select "Global Module Index" in contents tree (note availability of 
"Locate" button);

- Click "O" link;

- Click "optparse" link.

Note that contents remains collapsed and "Locate" button is 
unavailable. This makes navigating through the page a bit tiring. The 
Find functionality in the CHM viewer isn't great.

Also try:

- Load Windows CHM file;

- Select Index;

- Enter "optparse" in keyword field;

- Select "optparse (module)" entry in index.

Note lack of Locate button. This looks to be the same thing as 
selecting optparse from the module index (as it maybe is).

Also try:

- Load Windows CHM file;

- Expand "The Python Standard Library" folder in contents;

- ...expand "Generic Operating System Services" folder in contents;

- Click "optparse --- More powerful command line option parser" folder 
in contents (note optparse page appears again, but this time you can 
see the location line at the top, and Locate button remains available);

If one then collapses the "The Python Standard Library" folder, one is 
then almost where one was in the first set of steps. This time, though, 
one may click "Locate" to find the entry in the contents so that the 
page is a bit easier to navigate.

Also try:

- Load Windows CHM file;

- Select "Global Module Index" from content;

- Click "C" link;

- Select "Carbon.AE" link (note availability of Locate button).

In this case, the Locate button IS available. Same goes for some other 
sub-libraries -- e.g. compiler.ast and wsgiref.handlers -- but not all 
-- e.g., xml.dom.

Expected behaviour:

When navigating to any module's doc page from its entry in the global 
module index, or its entry in the index, or indeed by following any 
link in the docs, it should be possible to click "Locate" to find it in 
the contents tree. The document search facilities in the CHM viewer are 
a bit lame, so having the contents tree at hand is very useful (I might 
say essential -- but that could just be me).

(This was less of an issue in previous versions of the docs, because 
the pages were split up into parts, so one could use Back once or twice 
to get to the contents then click a link to go straight to the desired 
section.)

Thanks.

----------
assignee: georg.brandl
components: Documentation
messages: 92565
nosy: georg.brandl, tom_seddon
severity: normal
status: open
title: Sub-optimal "Locate" button behaviour in Windows CHM file
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Sun Sep 13 15:19:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Sep 2009 13:19:16 +0000
Subject: [issue6899] Base.replace breaks tree
In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
Message-ID: <1252847956.29.0.942264425603.issue6899@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Looks good, but it needs some tests.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6899>
_______________________________________

From report at bugs.python.org  Sun Sep 13 16:00:23 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 13 Sep 2009 14:00:23 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1252850423.22.0.0637359544374.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, this means that the exception is raised after the finally, when the 
thread is exiting.
Now, at this point the process is exiting and therefore we have trouble 
printing the exception.  (this is probably also the cause of the 
exception in the first place, some cleanup that fails because the 
process is exiting).
Now, the traceback printing code is complex and it could fail in a 
multitude of places, but from the stuff that is output, it would appear 
that printing to sys.stderr is failing.  To find out the error, we need 
to goad python into displaying the exception, even though the process is 
exiting.
On a windows machiine, I would put a DebugBreak() call in t_bootstrap() 
in threadmodule_t and try to find out where the error output code is 
failing.  I don't know if you can do just-in-time debugging on your 
machine.  It would be best, of course, to singlestep through the code at 
line 452 in threadmodule.c.  Then we could pinpoint where the output is 
failing and fix python to make it more resilient at process exit.

Now, lines 452-455 don't produce any output.  For starters, try to 
insert "file=0" before line 452 in threadmodule.c, so that 
PyObject_Print is called instead of PyFile_WriteObject() (which I think 
is failing.)
If that produces output, then we can proceed to hardwire "stderr" into 
the traceback stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Sun Sep 13 16:36:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Sep 2009 14:36:35 +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: <1252852595.97.0.653074541018.issue6108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a potentially annoying bug to me.

----------
nosy: +pitrou
priority:  -> high
stage:  -> needs patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Sep 13 17:32:20 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 13 Sep 2009 15:32:20 +0000
Subject: [issue6635] Profiler doesn't print usage (indexError instead)
In-Reply-To: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>
Message-ID: <1252855940.55.0.256395585003.issue6635@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fixed in 2.6, 2.7, 3.1, 3.2

----------
nosy: +doko
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6635>
_______________________________________

From report at bugs.python.org  Sun Sep 13 18:14:14 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 13 Sep 2009 16:14:14 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1252858454.85.0.21396642224.issue6301@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 74779.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Sun Sep 13 18:17:31 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Sep 2009 16:17:31 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252858651.66.0.529537252117.issue6882@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Sun Sep 13 18:18:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Sep 2009 16:18:00 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252858680.38.0.913365422205.issue6882@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/issue6882>
_______________________________________

From report at bugs.python.org  Sun Sep 13 18:40:30 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 13 Sep 2009 16:40:30 +0000
Subject: [issue6567] Make inf be almost equal to inf
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1252860030.73.0.822745746852.issue6567@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 74780.

----------
resolution: wont fix -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________

From report at bugs.python.org  Sun Sep 13 18:46:43 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 13 Sep 2009 16:46:43 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1252860403.39.0.0789958367072.issue6712@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 74781.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Sun Sep 13 19:07:31 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 13 Sep 2009 17:07:31 +0000
Subject: [issue5135] Expose simplegeneric function in functools module
In-Reply-To: <1233604660.52.0.0984436233806.issue5135@psf.upfronthosting.co.za>
Message-ID: <1252861651.26.0.461860283686.issue5135@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Please don't introduce this without a PEP.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5135>
_______________________________________

From report at bugs.python.org  Sun Sep 13 19:08:02 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 13 Sep 2009 17:08:02 +0000
Subject: [issue6849] Tutorial changes
In-Reply-To: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
Message-ID: <1252861682.39.0.697506653824.issue6849@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 74782.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6849>
_______________________________________

From report at bugs.python.org  Sun Sep 13 19:28:52 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 13 Sep 2009 17:28:52 +0000
Subject: [issue6866] TestLoader.loadTestsFromName does not use suiteClass
	attribute to create TestSuite instances
In-Reply-To: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>
Message-ID: <1252862932.86.0.98193456346.issue6866@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 74783.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6866>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:10:51 2009
From: report at bugs.python.org (Bernie H. Innocenti)
Date: Sun, 13 Sep 2009 18:10:51 +0000
Subject: [issue6901] Runaway programs often become unresponsive to CTRL-C
In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
Message-ID: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>


New submission from Bernie H. Innocenti <bernie at codewiz.org>:

On startup, the Python interpreter changes the default behavior
of SIGINT, which results in  many Python programs to ignore the
keyboard interrupt exactly in the situations when users are
most likely to use it (i.e.: when the program becomes unresponsive).

Minimal testcase:
 $ echo "void foo() { for(;;) {} }" >foo.c
 $ gcc -shared -o foo.so foo.c
 $ python -c 'import ctypes;ctypes.CDLL("./foo.so").foo()'
 ^C^C^C
 ^C
 ^C DAMN!
 ^C

This scenario mimics a Python program calling some blocking library
function.  It can also happen with IO-bound functions if they loop
on read() and don't abort on short reads.

One might be tempted to say "this behavior of the Python intepreter
is by design" and suggest users to use CTRL-\ instead of CTRL-C.
However, this non-standard behavior is very annoying for users who
expect ^C to work on UNIX systems.  In fact, no other compiled or
interpreted language I know of behaves this way, and Python should
not be the only exception.

While I see the usefulness of KeyboardInterrupt from the programmer
point of view, only a minority of programs actually need to trap
SIGINT and do something with it.  Other language runtimes require
the programmer to manually trap SIGINT when needed.  The Python
interpreter could maintain backwards compatibility by enabling
automatic SIGINT trapping when entering a  "try" block that would
intercept KeyboardInterrupt.

----------
components: Interpreter Core
messages: 92576
nosy: bernie
severity: normal
status: open
title: Runaway programs often become unresponsive to CTRL-C
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6901>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:18:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Sep 2009 18:18:15 +0000
Subject: [issue6901] Runaway programs often become unresponsive to CTRL-C
In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
Message-ID: <1252865895.26.0.549599003979.issue6901@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is a fundemental behavior that will never change. If you dislike
it, you can remove the signal handler for it with the signal module.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6901>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:32:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Sep 2009 18:32:45 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252866765.0.0.374254946295.issue6871@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think issue #4 is a bug in float formatting:  I don't think it makes 
sense to change alignment just because the fill character happens to be 
'0'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:33:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Sep 2009 18:33:48 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252866827.97.0.760435149975.issue6871@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>From the current trunk:

>>> format(float('1e88'), '1<20')
'1e+88111111111111111'
[64734 refs]
>>> format(float('1e88'), '0<20')
'0000000000000001e+88'
[64734 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:36:00 2009
From: report at bugs.python.org (Bernie H. Innocenti)
Date: Sun, 13 Sep 2009 18:36:00 +0000
Subject: [issue6901] Runaway programs often become unresponsive to CTRL-C
In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
Message-ID: <1252866960.0.0.799286665465.issue6901@psf.upfronthosting.co.za>


Bernie H. Innocenti <bernie at codewiz.org> added the comment:

> This is a fundemental behavior that will never change. If you
> dislike it, you can remove the signal handler for it with the
> signal module.

What?  We could break the syntax of "print" statements and
cannot change this minor detail that afftects many 1% of all
Python programs?

As a matter of fact, for 2 years I've been using this in my
/usr/lib64/python2.6/sitecustomize.py:

----cut-----
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
----cut-----

^C has been working perfectly ever since.  So far, I have not
yet found a single Python program where restoring the default
behavior of SIGINT causes real issues, but there may certainly
be a few.

Granted, this is just a kludge, not a perfect fix, but from a
user perspective, it already improves upon the current behavior
(i.e. more pros than cons).

At least, this is my personal experience.  If you're skeptical,
please try this workaround yourself for a few months and let me
know what breaks for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6901>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:40:30 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Sep 2009 18:40:30 +0000
Subject: [issue6901] Runaway programs often become unresponsive to CTRL-C
In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
Message-ID: <1252867230.26.0.0897566139415.issue6901@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Regardless of whether this is a good idea or not, it's too broad a
change for the bug tracker. Please bring it up on python-ideas if you
wish to pursue the topic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6901>
_______________________________________

From report at bugs.python.org  Sun Sep 13 20:48:33 2009
From: report at bugs.python.org (Bernie H. Innocenti)
Date: Sun, 13 Sep 2009 18:48:33 +0000
Subject: [issue6901] Runaway programs often become unresponsive to CTRL-C
In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
Message-ID: <1252867713.0.0.453126640288.issue6901@psf.upfronthosting.co.za>


Bernie H. Innocenti <bernie at codewiz.org> added the comment:

Ok

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6901>
_______________________________________

From report at bugs.python.org  Sun Sep 13 21:07:24 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 13 Sep 2009 19:07:24 +0000
Subject: [issue6568] unittest test discovery improvements
In-Reply-To: <1248477367.35.0.856395228547.issue6568@psf.upfronthosting.co.za>
Message-ID: <1252868844.31.0.552845793291.issue6568@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 74785.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6568>
_______________________________________

From report at bugs.python.org  Sun Sep 13 23:12:56 2009
From: report at bugs.python.org (Gawain Bolton)
Date: Sun, 13 Sep 2009 21:12:56 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1252876376.26.0.257118125661.issue6713@psf.upfronthosting.co.za>


Gawain Bolton <gp.bolton at computer.org> added the comment:

Mark,
I haven't tried your latest patch but I tried your patch3 and obtained 
the same performance improvement for long integers, namely 3.1x faster.
This is truly an excellent improvement, my hat's off to you!

As for the basic integers, I'm working on another patch which improves
performance even more but by all means, go ahead with your improvement
for long integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Mon Sep 14 01:29:57 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Sep 2009 23:29:57 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252884597.2.0.471106538804.issue6871@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The '0' fill character is forcing '=' alignment (per the PEP). This
looks like a bug to me, since it should use the specified alignment.

This is not a float-only problem, it applies to the other built-in types
as well:
>>> format(2, '0<20')
'00000000000000000002'
>>> format(2, '1<20')
'21111111111111111111'

There are too many distinct issues combined here, I'll create a new
issue just for this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Mon Sep 14 01:36:45 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Sep 2009 23:36:45 +0000
Subject: [issue6902] Built-in types format incorrectly with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Originally discussed in issue 6871. Even if an alignment of "<" is
specified, "=" is used if the padding character is "0".

>>> format(2, '0<20')
'00000000000000000002'
>>> format(2, '1<20')
'21111111111111111111'

This is a problem for at least float and integers.

This should probably be backported to 2.6 and 3.1, but I'll have to wait
and see how invasive the patch is.

----------
assignee: eric.smith
components: Interpreter Core
messages: 92586
nosy: eric.smith, marketdickinson, skrah
priority: normal
severity: normal
status: open
title: Built-in types format incorrectly with 0 padding.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6902>
_______________________________________

From report at bugs.python.org  Mon Sep 14 01:38:28 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Sep 2009 23:38:28 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252885108.5.0.588547260127.issue6871@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Created issue 6902 to handle #4.

The others will need to be broken out into their own issues if we want
to fix them. I can't keep track of multiple issues in one bug report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Mon Sep 14 02:18:25 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 14 Sep 2009 00:18:25 +0000
Subject: [issue6903] pdb - print in for iteration prints None after printing
In-Reply-To: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za>
Message-ID: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Near the bottom of the library documentation for pdb there is an example
of a very useful alias:

alias pi for k in %1.__dict__.keys(): print("%1.",k,"=",%1.__dict__[k])

It turns out that doing print in a for loop in pdb results in None being
printed on a line after each print. For example:

(Pdb) 
for n in range(3): print(n)
0
None
1
None
2
None
(Pdb) 

Seems like a (minor) bug, but if not, the example should be removed or
replaced in the documentation.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 92588
nosy: MLModel, georg.brandl
severity: normal
status: open
title: pdb - print in for iteration prints None after printing
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6903>
_______________________________________

From report at bugs.python.org  Mon Sep 14 02:37:26 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Mon, 14 Sep 2009 00:37:26 +0000
Subject: [issue6904] Broken URL for pyqt
In-Reply-To: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za>
Message-ID: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za>


New submission from Thijs Triemstra <lists at collab.nl>:

using/mac.html#gui-programming-on-the-mac refers to 
http://www.riverbankcomputing.co.uk/pyqt/ but this should be 
http://www.riverbankcomputing.co.uk/software/pyqt

----------
assignee: georg.brandl
components: Documentation
messages: 92589
nosy: georg.brandl, thijs
severity: normal
status: open
title: Broken URL for pyqt
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6904>
_______________________________________

From report at bugs.python.org  Mon Sep 14 02:42:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Sep 2009 00:42:00 +0000
Subject: [issue6904] Broken URL for pyqt
In-Reply-To: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za>
Message-ID: <1252888920.15.0.218227208672.issue6904@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6904>
_______________________________________

From report at bugs.python.org  Mon Sep 14 02:58:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Sep 2009 00:58:18 +0000
Subject: [issue6904] Broken URL for pyqt
In-Reply-To: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za>
Message-ID: <1252889898.05.0.07413819108.issue6904@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74787 (trunk) and r74788 (py3k), thanks!

----------
priority:  -> low
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6904>
_______________________________________

From report at bugs.python.org  Mon Sep 14 05:54:51 2009
From: report at bugs.python.org (Yuv Gre)
Date: Mon, 14 Sep 2009 03:54:51 +0000
Subject: [issue6905] inspect.getargspec(print) fails
In-Reply-To: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>
Message-ID: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

>>> import inspect
>>> inspect.getargspec(print)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "F:\Python31\lib\inspect.py", line 787, in getargspec
    getfullargspec(func)
  File "F:\Python31\lib\inspect.py", line 814, in getfullargspec
    raise TypeError('arg is not a Python function')
TypeError: arg is not a Python function

Is this normal or a known issue? I couldn't find an existing ticket.

----------
components: Library (Lib)
messages: 92591
nosy: ubershmekel
severity: normal
status: open
title: inspect.getargspec(print) fails
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6905>
_______________________________________

From report at bugs.python.org  Mon Sep 14 09:04:18 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Mon, 14 Sep 2009 07:04:18 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1252911858.9.0.0366363165278.issue6784@psf.upfronthosting.co.za>


RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

i'll try to add some tests now

hopefully i can get rid of the implicit badness like trying to coerce
bytes to unicode in unpickle and storing bytes as list in pickle for
protocol < 3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Mon Sep 14 10:32:44 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Mon, 14 Sep 2009 08:32:44 +0000
Subject: [issue6897] imaplib fails during login
In-Reply-To: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za>
Message-ID: <1252917164.51.0.230433450994.issue6897@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Looks like duplicate of #6734.

----------
nosy: +marcin.bachry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6897>
_______________________________________

From report at bugs.python.org  Mon Sep 14 11:29:26 2009
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=)
Date: Mon, 14 Sep 2009 09:29:26 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>


New submission from Micha? Pasternak <michal.dtz at gmail.com>:

Hi,

I was recently playing with txAmpoule & Twisted on win32. When Twisted spawns processess, the 
environment is checked for unicode variables (and an exception is raised in case of). Then it 
came to my attention, that importing Tkinter on win32 sets an environment variable, which value 
is Unicode. Just have a look:

C:\>python
ActivePython 2.6.2.2 (ActiveState Software Inc.) based on
Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> import os
>>> os.environ['TK_LIBRARY']
u'C:\\Python26\\tcl\\tk8.5'
>>> ^Z

Why is it Unicode? Does it really have to be? Do we need that environment variable at all?

On Linux, it is different:

root at foo:~# python
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 Tkinter
>>> import os
>>> os.environ['TK_LIBRARY']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
    raise KeyError(key)
KeyError: 'TK_LIBRARY'

----------
components: Tkinter
messages: 92594
nosy: dotz
severity: normal
status: open
title: Tkinter sets an unicode environment variable on win32
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________

From report at bugs.python.org  Mon Sep 14 11:44:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Sep 2009 09:44:48 +0000
Subject: [issue6905] inspect.getargspec(print) fails
In-Reply-To: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>
Message-ID: <1252921488.38.0.0968102642187.issue6905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is not an issue, but a fundamental restriction of what getargspec()
can do.  C function signatures are not introspectable, because basically
every C function can be thought of as defined as either

  def func(*args)

or 

  def func(*args, **kwargs)

and is free to do what it wants with the args and kwargs.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6905>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:20:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:20:21 +0000
Subject: [issue6907] xmlrpclib.make_connection() is not thread safe
In-Reply-To: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>
Message-ID: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The issue #6099 (part of #6267 superset) introduced a regression:
xmlrpclib.make_connection() is not thread safe. If xmlrpclib is used in two
threads, the socket is shared, but it doesn't any lock, and so data will be
mixed between the two requets. It becomes worse when I use SSL (pyopenssl
or m2crypto).

A possible solution is to use a different socket for each thread.

Note: I really love #6099, it was exactly what I needed :-)

----------
components: Extension Modules
messages: 92596
nosy: haypo
severity: normal
status: open
title: xmlrpclib.make_connection() is not thread safe
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6907>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:40:17 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:40:17 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1252924817.23.0.754704010263.issue6267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened a bug report introduced by this issue: #6907:
xmlrpclib.make_connection() is not thread safe.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:41:49 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:41:49 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1252924909.72.0.0909132913274.issue1767370@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that this issue is a duplicate of #6267 which is already commited to
Python trunk. #6267 is a superset of #6099.

See also #2076 (another duplicate of #6267 ?).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:44:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:44:33 +0000
Subject: [issue2076] xmlrpclib closes connection after each call
In-Reply-To: <1202814252.95.0.393197834217.issue2076@psf.upfronthosting.co.za>
Message-ID: <1252925073.52.0.96705611286.issue2076@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that xmlrpclib is already fixed in Python trunk. See #6267. I consider
this issue as a duplicate of #6267.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2076>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:44:43 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:44:43 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1252925083.61.0.536461476275.issue6267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are duplicate issues about HTTP/1.1: #2076, #1767370.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:48:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:48:23 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1252925303.38.0.843191561662.issue1613573@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I consider this issue as a duplicate of #6267 which is already fixed (commited).
Reopen the issue if I'm wrong ;-)

See also #2076 and #1767370 (other duplicates).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:49:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:49:01 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1252925341.75.0.412769430348.issue1613573@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:49:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:49:30 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1252925370.72.0.00724778282739.issue6267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another duplicate: #1613573.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Mon Sep 14 12:58:54 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:58:54 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1252925934.67.0.888245180066.issue6791@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/issue6791>
_______________________________________

From report at bugs.python.org  Mon Sep 14 13:10:52 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 14 Sep 2009 11:10:52 +0000
Subject: [issue6907] xmlrpclib.make_connection() is not thread safe
In-Reply-To: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>
Message-ID: <1252926652.97.0.782047315783.issue6907@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

the xmlrpclib.ServerProxy is not thread safe, no.  Nor is it designed to 
be.  the documentation never claims that it is and the fact that the old 
version was (due to a new HTTPConnection being created each time) is a 
coincidence than a design feature.
In my own client code I use a pool of ServerProxy objects for each 
thread to claim and use one at a time.  This way I can have many 
simultaneous requests to the same server going.
You can also create your own lock and share a ServerProxy among threads.

Also note that HTTPConnection is not thread safe either.  And in 
general, class instances in the lib are not thread safe unless 
explicitly documented to be so.

----------
nosy: +krisvale
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6907>
_______________________________________

From report at bugs.python.org  Mon Sep 14 13:12:32 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 14 Sep 2009 11:12:32 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1252926752.87.0.935864333957.issue1767370@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, it is indeed a duplicate.

----------
nosy: +krisvale
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Mon Sep 14 13:15:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 11:15:22 +0000
Subject: [issue6907] xmlrpclib.make_connection() is not thread safe
In-Reply-To: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>
Message-ID: <1252926922.36.0.807572246609.issue6907@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@krisvale: You changed the resolution to invalid, but you leaved the state
unchanged (open). Ok, I agree that the stdlib is not thread safe, and so I
closed this issue.

I saw this issue as a regression because the previous version (using a different
socket for each XML-RPC request) was thread sae (even if it wasn't designed
to be thread safe) :-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6907>
_______________________________________

From report at bugs.python.org  Mon Sep 14 13:16:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 11:16:01 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1252926961.22.0.873328381194.issue1767370@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/issue1767370>
_______________________________________

From report at bugs.python.org  Mon Sep 14 13:16:57 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 11:16:57 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1252927017.7.0.90644505879.issue6267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, all duplicate issues are now closed (#1613573, #1767370, #2076).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Mon Sep 14 13:59:10 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 14 Sep 2009 11:59:10 +0000
Subject: [issue6902] Built-in types format incorrectly with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1252929550.17.0.575510538996.issue6902@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

complex will also need to be addressed. The second error message is
misleading, for the same reason the formatting on float and int is
incorrect:

>> format(3-2j, "0<30")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Zero padding is not allowed in complex format specifier
>>> format(3-2j, "0=30")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Zero padding is not allowed in complex format specifier

But this is correct:
>>> format(3-2j, "=30")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: '=' alignment flag is not allowed in complex format specifier

It's not 0 padding that's not allowed, it's the implied sign alignment
when using 0 (without a specified alignment).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6902>
_______________________________________

From report at bugs.python.org  Mon Sep 14 15:11:11 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 14 Sep 2009 13:11:11 +0000
Subject: [issue1019715] distutils ignores configure's --includedir
Message-ID: <1252933871.61.0.814620269638.issue1019715@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Yes, this is a duplicate of issue858809 and tarek is assigned to that
one too.

----------
nosy: +orsenthil
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1019715>
_______________________________________

From report at bugs.python.org  Mon Sep 14 16:00:29 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 14:00:29 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1252936829.59.0.725249917825.issue6574@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

Implemented proposed changes.

Additionally, I'd change line 13 to state either "future statements" or
"`future`:ref:" instead of "future_statements", which does not make
sense in normal, unmarked text.

----------
Added file: http://bugs.python.org/file14885/future.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________

From report at bugs.python.org  Mon Sep 14 16:09:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Sep 2009 14:09:07 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1252937347.5.0.226535977685.issue6574@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I added a reference in line 13, changed the table header not to use
colspans (the latex writer doesn't support that), and committed as r74791.

----------
assignee: ezio.melotti -> georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________

From report at bugs.python.org  Mon Sep 14 16:15:43 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 14:15:43 +0000
Subject: [issue6574] List the __future__ features in a table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1252937743.39.0.908901153415.issue6574@psf.upfronthosting.co.za>


Changes by Robert Lehmann <lehmannro at gmail.com>:


Added file: http://bugs.python.org/file14886/future.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________

From report at bugs.python.org  Mon Sep 14 16:47:20 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 14:47:20 +0000
Subject: [issue6908] Minor markup error in hashlib docs
In-Reply-To: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za>
Message-ID: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The documentation for hashlib.hash.digest_size/block_size (notice the
hash) renders as documentation for hashlib.*_size, which does not exist.

Fixed by explicitly declaring membership; patch attached.

----------
assignee: georg.brandl
components: Documentation
files: hashlib-docs.patch
keywords: patch
messages: 92611
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Minor markup error in hashlib docs
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14887/hashlib-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6908>
_______________________________________

From report at bugs.python.org  Mon Sep 14 16:51:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Sep 2009 14:51:02 +0000
Subject: [issue6908] Minor markup error in hashlib docs
In-Reply-To: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za>
Message-ID: <1252939862.98.0.8995168817.issue6908@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74793.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6908>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:11:08 2009
From: report at bugs.python.org (jeff deifik)
Date: Mon, 14 Sep 2009 15:11:08 +0000
Subject: [issue6909] python 3.1 - filecmp.cmp exception based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I am calling filecmp.cmp on a two files, one of which has a name of

'./Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3'

I get an exception from filecmp.cmp saying:
 'ascii' codec can't encode character '\udce9' in position 37: ordinal
not in range(128)

I do not understand why filecmp.cmp cares what the encoding of the names
of the files are, as long as they are valid files. I would think
filecmp.cmp would only care about the content of the files.

When I give it pure ascii names, filecmp.cmp works file, however some of
my files have udce9 encoded names.

This is on a windows xp machine running cygwin (linux emulation).
I built and compiled python3.1 from source.

----------
messages: 92613
nosy: jdeifik
severity: normal
status: open
title: python 3.1 - filecmp.cmp exception based on file name
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:19:41 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 14 Sep 2009 15:19:41 +0000
Subject: [issue6910] 1-char typo in language reference doc of import
In-Reply-To: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za>
Message-ID: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Just before 6.11.1 of the Language Reference:

"Attempting to use it in class for function definitions"

should be "or" not "for"

----------
assignee: georg.brandl
components: Documentation
messages: 92614
nosy: MLModel, georg.brandl
severity: normal
status: open
title: 1-char typo in language reference doc of import
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6910>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:20:30 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Sep 2009 15:20:30 +0000
Subject: [issue6909] python 3.1 - filecmp.cmp exception based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252941630.81.0.829588776953.issue6909@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Could you paste your code?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:27:00 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 15:27:00 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

asynchat.async_chat grew a _collect_incoming and a _get_data method in
2.6. The constructor has been extended to conform to
asyncore.dispatcher's. This should be documented.

Apart from that, fifo and simple_producer have been deprecated, and
async_chat.ac_out_buffer was replaced by async_chat.incoming. These are
internals and were never documented.

A patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: asynchat-docs.patch
keywords: patch
messages: 92616
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Document changes in asynchat
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14888/asynchat-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6911>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:30:57 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Sep 2009 15:30:57 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1252942257.29.0.789710276873.issue6911@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> josiahcarlson
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6911>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:38:49 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 15:38:49 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1252942729.15.0.540648654534.issue6911@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

Excuse me -- fifo and simple_producer are indeed documented and need a
deprecation notice. New patch attached (plus reworded paragraph about
async_chat.__init__).

----------
Added file: http://bugs.python.org/file14889/asynchat-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6911>
_______________________________________

From report at bugs.python.org  Mon Sep 14 17:46:57 2009
From: report at bugs.python.org (jeff deifik)
Date: Mon, 14 Sep 2009 15:46:57 +0000
Subject: [issue6909] python 3.1 - filecmp.cmp exception based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252943217.59.0.342926485886.issue6909@psf.upfronthosting.co.za>


jeff deifik <jeff at jeffunit.com> added the comment:

Forgive all the print statements.

Here is the result of running this:

floup:files are
['./Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3',
'/cygdrive/j/music/bea/Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3']
l is greater than 1
i and j 0 1
two files 0 1
two files ./Jul /cygd
try two files 0 1
try two files (5) ./Jul /cygd
try two files exception =  'ascii' codec can't encode character '\udce9'
in position 37: ordinal not in range(128)


# Compare all files with the same size to each other
def look_through_table(the_tab):
    global Options
    # loop through file sizes that
    for size in list(the_tab.keys()):
        files = the_tab[size]		# List of all files with same size
        l = len(files)
        print('floup:files are', files)
        if l > 1:
            print('l is greater than 1')
            for i in range(l):
                for j in range(i + 1, l):
                    print('i and j', i, j)
                    print('two files', i, j)
                    print('two files', files[i][0:5], files[j][0:5])

                    if Options.name == False or \
                            os.path.basename(files[i]) ==
os.path.basename(files[j]):
                        # print 'cmp_two_files', files[i], files[j], \
                        #        cmp_two_files(files[i], files[j])
                        try:
                            print('try two files', i, j)
                            print('try two files (5)', files[i][0:5],
files[j][0:5])
                            print('try two files', files[i], files[j])
                            if filecmp.cmp(files[i], files[j], False):
                                print('MATCHED')
                                print(files[i])
                                print(" and ", files[j])
                            else:
                                print('DID NOT MATCH')
                        except Exception as inst:
                            print('exception = ', inst)
                            pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________

From report at bugs.python.org  Mon Sep 14 18:10:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Sep 2009 16:10:57 +0000
Subject: [issue6909] python 3.1 - filecmp.cmp exception based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252944657.18.0.116546916773.issue6909@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You should try removing the try/except to find out which line is
actually throwing the error.  I think you will find that it is the print
statement.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________

From report at bugs.python.org  Mon Sep 14 18:25:19 2009
From: report at bugs.python.org (jeff deifik)
Date: Mon, 14 Sep 2009 16:25:19 +0000
Subject: [issue6909] python 3.1 - filecmp.cmp exception based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252945519.08.0.657811249012.issue6909@psf.upfronthosting.co.za>


jeff deifik <jeff at jeffunit.com> added the comment:

Oops, you are correct, my mistake.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________

From report at bugs.python.org  Mon Sep 14 18:26:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Sep 2009 16:26:14 +0000
Subject: [issue6909] python 3.1 - filecmp.cmp exception based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252945574.14.0.375376383974.issue6909@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________

From report at bugs.python.org  Mon Sep 14 18:32:14 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Sep 2009 16:32:14 +0000
Subject: [issue6910] 1-char typo in language reference doc of import
In-Reply-To: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za>
Message-ID: <1252945934.14.0.254824451219.issue6910@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6910>
_______________________________________

From report at bugs.python.org  Mon Sep 14 18:49:24 2009
From: report at bugs.python.org (Michal Hordecki)
Date: Mon, 14 Sep 2009 16:49:24 +0000
Subject: [issue6234] cgi.FieldStorage is broken when given POST data
In-Reply-To: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>
Message-ID: <1252946964.62.0.792304921656.issue6234@psf.upfronthosting.co.za>


Michal Hordecki <mhordecki at gmail.com> added the comment:

It is because FieldStorage requires str, whereas wsgi.input gives bytes.

You can always wrap environ['wsgi.input'] in TextIOWrapper.

----------
nosy: +MHordecki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6234>
_______________________________________

From report at bugs.python.org  Mon Sep 14 19:57:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2009 17:57:28 +0000
Subject: [issue6912] Add 'with' block support to Tools/Scripts/pindent.py
In-Reply-To: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za>
Message-ID: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

As reported by Miles Kaufmann on python-list, 
Tools/Scripts/pindent.py
has not been updated to support 'with' blocks.

I suspect that it would be sufficient to add ",'with'" to
start = 'if', 'while', 'for', 'try', 'def', 'class'

Since there are no "next['def'/'class']" lines, I suspect none is needed
for 'with' either.

----------
components: Demos and Tools
messages: 92622
nosy: tjreedy
severity: normal
status: open
title: Add 'with' block support to Tools/Scripts/pindent.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6912>
_______________________________________

From report at bugs.python.org  Mon Sep 14 20:08:30 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 14 Sep 2009 18:08:30 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252951710.72.0.26289793546.issue6247@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Why does this have to go into the standard library? People that want to
use it can still install it from PyPI. -sys.maxint from me.

----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 20:11:42 2009
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 14 Sep 2009 18:11:42 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252951902.5.0.050142621061.issue6247@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

@Armin: Doesn't that argument apply to *any* library proposed for
inclusion in the standard library? By which logic we should never add
anything to the standard library ever again. Surely you don't mean that,
so could you be more specific on what you think is particularly
inappropriate about argparse?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 20:15:34 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 14 Sep 2009 18:15:34 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252952134.15.0.145663772082.issue6247@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> @Armin: Doesn't that argument apply to *any* library proposed for
> inclusion in the standard library? By which logic we should never add
> anything to the standard library ever again.

That's what I say. Do not add anything to the stdlib that is not needed
to keep applications platform independent. argparse adds zero value to
x-platform development.

Things I consider good for a stdlib:

  * portable filesystem notification hooks
  * stuff like os.path
  * distutils
  * socket library

Stuff that should not go into the stdlib:

  * xml parsers
  * command line parsers (one is enough, and that should be
    *stable* not replaced later with something like argparse)

Fix packaging and do not dump useless stuff into the standard library to
make it appear more modern. Decentralization is modern, not replacing
modules in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 20:25:55 2009
From: report at bugs.python.org (Daniel Eloff)
Date: Mon, 14 Sep 2009 18:25:55 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1252952755.22.0.596770919167.issue6281@psf.upfronthosting.co.za>


Daniel Eloff <dan.eloff at gmail.com> added the comment:

I have indeed seen __get_builtin_constructor fail in practice, in the 
python build in the Ubuntu repository if IIRC. I seem to recall the 
problem was that python was using a version of openssl that didn't 
include all of hash algorithms, probably because a python library or the 
process hosting python also had a dependency on libssl and had it loaded 
already.

But there is also the issue that Python is a language with many 
implementations now, and in fact, it's unlikely that CPython will remain 
the defacto implementation forever. Having a more robust hashlib.py that 
can handle missing algorithm implementations makes a lot of sense (.NET 
for example has no implementation of some of the more esoteric SHA 
hashes.) I remember that in the early days of IronPython, hashlib.py had 
to be completely replaced to be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Mon Sep 14 20:52:34 2009
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 14 Sep 2009 18:52:34 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1252952134.15.0.145663772082.issue6247@psf.upfronthosting.co.za>
Message-ID: <d11dcfba0909141152r5d604137la7ff0628382713e0@mail.gmail.com>


Steven Bethard <steven.bethard at gmail.com> added the comment:

[snip]
> Fix packaging and do not dump useless stuff into the standard library to
> make it appear more modern. Decentralization is modern, not replacing
> modules in the stdlib.

I can respect that viewpoint. So what do you propose to do with
existing modules like optparse that aren't required to make platform
independent applications and are out of date and basically
unmaintained? One option would be to remove them, but that's probably
too drastic. Another option would be to add documentation to them
warning that they're out of date and pointing users to alternative
external libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 20:55:42 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 14 Sep 2009 18:55:42 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252954542.1.0.212398045406.issue6247@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> I can respect that viewpoint. So what do you propose to do with
> existing modules like optparse that aren't required to make platform
> independent applications and are out of date and basically
> unmaintained? One option would be to remove them, but that's probably
> too drastic.

Documentation and a new kind of deprecation warning.  It's
documentation-deprecated in one version, one later a real deprecation
warning appears that sticks around for a couple of versions.  The
documentation would explain how to hide the deprecation warning and
tells the user to better use more modern alternatives.

This of course requires packaging to work flawlessly first which I
consider to be high priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 21:52:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Sep 2009 19:52:17 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252957937.69.0.550421892636.issue6247@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I disagree.  I think option and argument parsing belongs in the standard
(batteries included) library, regardless of how well external package
management works.  

argparse has the advantage over optparse that it has an active
maintainer.  What we do about the stuff in the stdlib that is no longer
maintained is a different discussion, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 21:58:09 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 14 Sep 2009 19:58:09 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252958289.13.0.0505921922972.issue6247@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Command line parsing is a basic need, including amongst other standard
library modules. argparse has many advantages over optparse (not the
least of which is that it has an active maintainer). Several of these
features *can't* be added to optparse whilst maintaining backwards
compatibility, which is what prompted Steven to create argparse in the
first place.

Improvements that I am aware of include:

- handling of standard Windows way of specifying options
- sub-commands
- handling of positional arguments

I had to implement my own technique for handling a sub-command in recent
unittest changes that would have been much simpler if argparse were in
the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 22:36:09 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Sep 2009 20:36:09 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252960569.19.0.976336359625.issue6247@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It must be convenient to operate in an environment where you can install
new software so easily Armin.

For those of us that operate in environments where every new piece of
software has to go through contracts review to ensure that we can both
license it for our own purposes and also subsequently transfer those
licenses to our customers, having things in the standard library is a
*huge* benefit.

This is the usual batteries included vs better packaging argument. For
developers in an environment where adding new packages is a low overhead
operation, adding something to the stdlib isn't a big gain for them
while better packaging tools are awesome. For others (including me), the
actual package installation is the least of our hassles and anything
that helps us avoid dealing with the lawyers is a big gain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 22:53:36 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 14 Sep 2009 20:53:36 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252961616.07.0.0255183712464.issue6247@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> It must be convenient to operate in an environment where you can 
> install new software so easily Armin.

Trust me, it is.

> For others (including me), the actual package installation is the
> least of our hassles and anything that helps us avoid dealing with
> the lawyers is a big gain.

So you're suggesting Python should suffer because some companies have a
weird legal department?

@Michael Foord: I totally agree that argument parsing is something that
*should* be in the standard library because everybody needs it.  However
at the same time it's something I could imagine comes from an external
source.  I would rather maintain optparse myself for python.org than
seeing another argument parsing library in the stdlib so that everybody
has to switch over because the Python devs did not find someone to
maintain it.  The stdlib is very often unmaintained for large parts; we
can't just replace a module because the developer got bored...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 23:00:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Sep 2009 21:00:12 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252962012.41.0.531331772995.issue6247@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think optparse just got a new maintainer.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 23:02:09 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 14 Sep 2009 21:02:09 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252962129.79.0.278273585083.issue6247@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

He has a few important feature requests to deal with as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Mon Sep 14 23:18:29 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Mon, 14 Sep 2009 21:18:29 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1252963109.39.0.242365661445.issue6412@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Implementing full patch solving it the old way (UTR#21).

The correct way for the latest Unicode version would be to implement
the word breaking algorithm described in (UAX#29) [1] first.

[1] http://www.unicode.org/reports/tr29/#Word_Boundaries

----------
Added file: http://bugs.python.org/file14890/unicodeobject.titlecase.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Mon Sep 14 23:24:32 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Mon, 14 Sep 2009 21:24:32 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1252963472.53.0.554468837566.issue6412@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

I should add that I didn't include the two header files generated by
Tools/unicode/makeunicodedata.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Tue Sep 15 01:45:45 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Sep 2009 23:45:45 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1252952134.15.0.145663772082.issue6247@psf.upfronthosting.co.za>
Message-ID: <52dc1c820909141645s76546a56gd7174aec2b0be017@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

On Mon, Sep 14, 2009 at 11:15 AM, Armin Ronacher <report at bugs.python.org> wrote:
>
> Armin Ronacher <armin.ronacher at active-4.com> added the comment:
>
>> @Armin: Doesn't that argument apply to *any* library proposed for
>> inclusion in the standard library? By which logic we should never add
>> anything to the standard library ever again.
>
> That's what I say. Do not add anything to the stdlib that is not needed
> to keep applications platform independent. argparse adds zero value to
> x-platform development.

By that logic we should remove getopt and optparse,

>
> Things I consider good for a stdlib:
>
> ?* portable filesystem notification hooks
> ?* stuff like os.path
> ?* distutils
> ?* socket library
>
> Stuff that should not go into the stdlib:
>
> ?* xml parsers
> ?* command line parsers (one is enough, and that should be
> ? ?*stable* not replaced later with something like argparse)

One is only enough if its a useful one.  argparse can be that one.
optparse and getopt are both sorely lacking.  If anything deprecate
getopt and optparse so that they're gone in 3.4.

By your argument we shouldn't even have one command line parser
because it does nothing to cross platform support.

Please DO NOT drag an issue asking to add a useful library to the set
of batteries included into the packaging decentralization flamewar.
There are is a large python user base that can never code that does
not come as part of python itself for one or more of legal and
technical reasons.  This issue is not the place to debate how stupid
anyone thinks that concept is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Sep 15 02:01:46 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 15 Sep 2009 00:01:46 +0000
Subject: [issue1115886] os.path.splitext don't handle unix hidden file
	correctly
In-Reply-To: <1252102566.68.0.256901206152.issue1115886@psf.upfronthosting.co.za>
Message-ID: <20090915000134.GA4376@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

Alexandru: You commented on a closed issue. If you see any problem
with mimetypes.guess_type() w.r.t to .ogg files, please open a new
open stating your problem.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1115886>
_______________________________________

From report at bugs.python.org  Tue Sep 15 03:02:39 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Sep 2009 01:02:39 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1252976559.2.0.123143864141.issue6247@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Armin; if you are serious in wanting to help out with the stdlib and core 
work, feel free to help us discuss this over on the stdlib-sig 
(http://mail.python.org/pipermail/stdlib-sig/2009-September/000398.html) 
or help commit patches and fixes for all of the modules that are growing 
long in the tooth and need help.

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Sep 15 05:31:21 2009
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 15 Sep 2009 03:31:21 +0000
Subject: [issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792)
In-Reply-To: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za>
Message-ID: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

Py_SetPythonHome takes a *wchar_t not a *char, this is obvious from
looking at the header,

However I tried using this function and couldn't get it working until I
made the home variable a static string.

when looking at the source this is obvious, but should be documented...

void
Py_SetPythonHome(wchar_t *home)
{
	default_home = home;
}

----------
assignee: georg.brandl
components: Documentation
files: Py_SetPythonHome_doc.diff
keywords: patch
messages: 92640
nosy: georg.brandl, ideasman42
severity: normal
status: open
title: Py_SetPythonHome incorrectly documented py3.x (rev 74792)
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14891/Py_SetPythonHome_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6913>
_______________________________________

From report at bugs.python.org  Tue Sep 15 05:36:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Sep 2009 03:36:47 +0000
Subject: [issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792)
In-Reply-To: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za>
Message-ID: <1252985807.56.0.974035477923.issue6913@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74794 and r74795.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6913>
_______________________________________

From report at bugs.python.org  Tue Sep 15 06:07:18 2009
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 15 Sep 2009 04:07:18 +0000
Subject: [issue6914] Py_SetPythonHome, undocumented behavoir
In-Reply-To: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za>
Message-ID: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

Py_SetPythonHome holds a pointer to the variable passed, this is not
documented so passing a variable on the stack will not work as expected
unless its static or allocated.

----------
components: None
messages: 92642
nosy: ideasman42
severity: normal
status: open
title: Py_SetPythonHome, undocumented behavoir
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6914>
_______________________________________

From report at bugs.python.org  Tue Sep 15 06:43:16 2009
From: report at bugs.python.org (Ryan Kelly)
Date: Tue, 15 Sep 2009 04:43:16 +0000
Subject: [issue6915] os.listdir inconsistenly releases the GIL on win32
In-Reply-To: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za>
Message-ID: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

The win32 implementation of os.listdir() releases the GIL around calls
to FindNextFile, but not around calls to FindFirstFile.  Attached is a
simple patch to consistently release the GIL around any such calls.

----------
components: None
files: listdir_gil.patch
keywords: patch
messages: 92643
nosy: rfk
severity: normal
status: open
title: os.listdir inconsistenly releases the GIL on win32
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14892/listdir_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6915>
_______________________________________

From report at bugs.python.org  Tue Sep 15 07:31:44 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Tue, 15 Sep 2009 05:31:44 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1252992704.22.0.555938699696.issue6911@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I found another bug: async_chat.push still talks about automatically
creating a simple_producer, which is no longer true. 

I added a fix to the patch.

----------
Added file: http://bugs.python.org/file14893/asynchat-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6911>
_______________________________________

From report at bugs.python.org  Tue Sep 15 07:55:57 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Tue, 15 Sep 2009 05:55:57 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The patches in issue1736190 deprecated fifo and simple_producers. These
are safe for removal in Python 3.0.

I attached a patch purging fifo and simple_producers from py3k code and
tests. The docs are mostly trivial as well but also touched by my other
issue issue6911 so I'd like that to settle first, otherwise this might
result in a merge conflict.

----------
assignee: georg.brandl
components: Documentation, Library (Lib), Tests
files: asynchat.patch
keywords: patch
messages: 92645
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Remove deprecated items from asynchat
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14894/asynchat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________

From report at bugs.python.org  Tue Sep 15 09:20:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Sep 2009 07:20:43 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1252999244.0.0.710117304262.issue6916@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> josiahcarlson
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________

From report at bugs.python.org  Tue Sep 15 16:24:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Sep 2009 14:24:15 +0000
Subject: [issue6914] Py_SetPythonHome, undocumented behavoir
In-Reply-To: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za>
Message-ID: <1253024655.52.0.0869344470151.issue6914@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74795.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6914>
_______________________________________

From report at bugs.python.org  Tue Sep 15 17:25:24 2009
From: report at bugs.python.org (dauerbaustelle)
Date: Tue, 15 Sep 2009 15:25:24 +0000
Subject: [issue6917] ".et_folder" instead of "get_folder" in mailbox
	documentation
In-Reply-To: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za>
Message-ID: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za>


New submission from dauerbaustelle <jonas at lophus.org>:

In the mailbox documentation,
http://docs.python.org/library/mailbox.html#mailbox.Maildir..et_folder
should be named "get_folder" instead of ".et_folder".

----------
assignee: georg.brandl
components: Documentation
messages: 92647
nosy: dauerbaustelle, georg.brandl
severity: normal
status: open
title: ".et_folder" instead of "get_folder" in mailbox documentation
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/issue6917>
_______________________________________

From report at bugs.python.org  Tue Sep 15 20:19:54 2009
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 15 Sep 2009 18:19:54 +0000
Subject: [issue6517] configparser: add possibility to escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1253038794.39.0.949266443477.issue6517@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Tue Sep 15 20:39:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Sep 2009 18:39:00 +0000
Subject: [issue6917] ".et_folder" instead of "get_folder" in mailbox
	documentation
In-Reply-To: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za>
Message-ID: <1253039940.58.0.837062991093.issue6917@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6917>
_______________________________________

From report at bugs.python.org  Tue Sep 15 21:03:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Sep 2009 19:03:36 +0000
Subject: [issue6917] ".et_folder" instead of "get_folder" in mailbox
	documentation
In-Reply-To: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za>
Message-ID: <1253041416.42.0.75587025788.issue6917@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74799 (trunk), r74802 (py3k) and r74800/r74803
(release(26|31)-maint), thanks!

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6917>
_______________________________________

From report at bugs.python.org  Tue Sep 15 21:17:41 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 19:17:41 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1253042261.5.0.950262837866.issue6245@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in 74806 (trunk), 74807 (2.6), 74808 (3.x), 74809 (3.1)

----------
keywords:  -needs review, patch
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Tue Sep 15 21:20:29 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 19:20:29 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1253042429.54.0.591906780954.issue6245@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Tue Sep 15 21:24:06 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 19:24:06 +0000
Subject: [issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1253042646.51.0.00123127181587.issue6441@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I just commited a fix for this, the patch is present in all 4 active 
branches (2.6, 2.7, 3.1, 3.2)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6441>
_______________________________________

From report at bugs.python.org  Tue Sep 15 21:27:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 19:27:16 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1253042836.41.0.868978621771.issue6851@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

It seems that CoreFoundation doesn't like being loaded on a secondairy 
thread:

#0  0x00007fff8301bb90 in __CFInitialize ()
#1  0x00007fff5fc0d5ce in 
__dyld__ZN16ImageLoaderMachO11doImageInitERKN11ImageLoader11LinkContextE 
()
#2  0x00007fff5fc0d607 in 
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkCon
textE ()
#3  0x00007fff5fc0bcec in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#4  0x00007fff5fc0bc9d in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#5  0x00007fff5fc0bda6 in 
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#6  0x00007fff5fc08fbb in __dyld_dlopen ()
#7  0x00007fff84902d40 in dlopen ()
#8  0x000000010070a0d2 in py_dl_open ()
#9  0x00000001000bb4ed in PyEval_EvalFrameEx ()
(More stack frames follow...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________

From report at bugs.python.org  Tue Sep 15 22:07:50 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 20:07:50 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1253045270.97.0.484611256407.issue6851@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This probably means that the ctypes code in urllib.py needs to be ported 
to C, although we won't know if that helps until said C code is written 
:-(

Doing that would be a good idea anyway, while trying to create a 
workaround I noticed that the ctypes code is invalid anyway because 
there are not enough ctypes annotations when running in 64-bit mode 
(where sizeof(int) != sizeof(long))

In 32-bit mode you can avoid the crash by calling urllib.urlopen or 
urllib.proxy_bypass once on the main thread, but you have to use a 
qualified name ("localhost.localdomain", not "localhost").

----------
resolution:  -> accepted
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________

From report at bugs.python.org  Tue Sep 15 22:15:39 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 20:15:39 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1253045739.88.0.548966825668.issue6872@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

purpleidea : Whether or not indexes should be 0-based in general is beyond 
the scope of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6872>
_______________________________________

From report at bugs.python.org  Tue Sep 15 23:11:01 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 21:11:01 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253049061.85.0.0724569698473.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch is a slightly cleaner version of your patch. What I 
don't like is that I'm also using runtime detection of libedit, I'd 
prefer compile-time detection but that doesn't seem possible without 
doing that dtection in setup.py.

My changes w.r.t. your patch:
* Do the libedit detection once when the readline module is initialised.
* Place libedit support in "#ifdef __APPLE__" blocks, the code might
  work with other libedit's (such as the one in NetBSD) as well, 
  but I cannot test that and don't want to risk breaking other 
  platforms.
* Also patch readline.get_history_item
* Change readline.__doc__ when using libedit's readline emulation

The patch seems to work on fine, including browsing in ipython's history 
on 10.6.

PS. I mentioned ipython because I know there were issues with ipython 
and Apple's python when Leopard was just out. I don't use ipython myself 
and hence don't know if they have added workarounds in their code (or if 
Apple fixed the issues the ran into)

Marking this issue as 'needs review' for two reasons:
1) I'm not familiar with the readline code
2) I'd like to know if this patch is backport material

----------
keywords: +26backport, needs review
versions:  -Python 2.5, Python 3.0
Added file: http://bugs.python.org/file14895/readline-libedit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 15 23:13:42 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 21:13:42 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1253049222.95.0.337849879317.issue6872@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've added an updated patch to issue 6877 that implements the same 1-based 
indexing as GNU's readline and also adds a note to the documentation to 
warn users about the possibility of linking the readline module to 
libedit.

That patch would, possibly with clearer documentation, IMHO fix this 
issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6872>
_______________________________________

From report at bugs.python.org  Tue Sep 15 23:18:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 21:18:30 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1253049510.89.0.353924889266.issue6851@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________

From report at bugs.python.org  Tue Sep 15 23:21:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 21:21:19 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

When I compile the trunk on MacOS X 10.6 I get a compile (or rather 
link) error in ctypes:

ld: in build/temp.macosx-10.5-fat3-
2.7/Users/ronald/Projects/python/python-trunk-
clean/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o, unsupported 
encoding in FDE for architecture ppc

This makes it impossible to build a univeral binary Python framework on 
OSX 10.6.

I don't think I'm running into the same issue with PyObjC, it that works 
I'll port PyObjC's version of ppc-darwin to the version of libffi that's 
used by ctypes.

----------
assignee: ronaldoussoren
components: Macintosh, ctypes
messages: 92656
nosy: ronaldoussoren
priority: release blocker
severity: normal
status: open
title: ctypes compilation error on SnowLeopard
type: compile error
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Tue Sep 15 23:21:39 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 21:21:39 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253049699.86.0.613816109433.issue6864@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Tue Sep 15 23:28:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Sep 2009 21:28:48 +0000
Subject: [issue6907] xmlrpclib.make_connection() is not thread safe
In-Reply-To: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>
Message-ID: <1253050128.24.0.846578346882.issue6907@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah yes.
Sorry, I'm no good with this system.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6907>
_______________________________________

From report at bugs.python.org  Wed Sep 16 00:17:00 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 15 Sep 2009 22:17:00 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1253053020.87.0.476724672667.issue6860@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Right, thanks for noticing this.

Here's the change I am going to make:

The code will use command.get_command_name() *everywhere* for the help 
display.

This method implemented in Command does the following:

- if the attribute "command_name" is present, it is returned
- __class__.__name__ ortherwise.

Meaning that you can define the name you want in the class.

Notice that this is under-documented so I need to add some document
for that behavior/feature.

I will not push this change in 2.7 since I don't consider this as a 
bug.

----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Wed Sep 16 00:18:13 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 15 Sep 2009 22:18:13 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1253053093.79.0.147601040737.issue6516@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

#6856 was added by Lars, so I can move forward and work on this one.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Wed Sep 16 03:19:55 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 16 Sep 2009 01:19:55 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1253063995.17.0.899456248532.issue3561@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Wed Sep 16 03:35:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Sep 2009 01:35:19 +0000
Subject: [issue6910] 1-char typo in language reference doc of import
In-Reply-To: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za>
Message-ID: <1253064919.06.0.928973557161.issue6910@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74815 (py3k), thanks!

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6910>
_______________________________________

From report at bugs.python.org  Wed Sep 16 03:49:24 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Sep 2009 01:49:24 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1253065764.16.0.392126133224.issue6900@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Wed Sep 16 04:40:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Sep 2009 02:40:36 +0000
Subject: [issue6881] incorrect signature in doc for PyByteArray_Resize
In-Reply-To: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>
Message-ID: <1253068836.9.0.30731648051.issue6881@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The PyByteArrayIter_Type is also missing, and the arg names of several
functions don't match the ones in the C source in Objects/bytesobject.c .
It might also be a good idea to add sub-headers in the doc to group
these functions in the same way they are grouped in the .h file (i.e.
Type Object, Type check macros, Direct API functions, Macros).

----------
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6881>
_______________________________________

From report at bugs.python.org  Wed Sep 16 04:55:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Sep 2009 02:55:33 +0000
Subject: [issue6879] misstatement in example explanation using raise
In-Reply-To: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>
Message-ID: <1253069733.95.0.916509423203.issue6879@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The original was:
>>> raise NameError, 'HiThere'
Since now this form is deprecated, I would remove that paragraph altogether.
Instead, that paragraph should be replaced with:
"The sole argument to raise indicates the exception to be raised. This
must be either an exception instance or an exception class (a class that
derives from Exception)."
as it is now in the Py3 doc (possibly backporting r58076).

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6879>
_______________________________________

From report at bugs.python.org  Wed Sep 16 06:19:14 2009
From: report at bugs.python.org (Henri Hein)
Date: Wed, 16 Sep 2009 04:19:14 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>


New submission from Henri Hein <henri at granitetower.net>:

Suggestion:  Link the CRT statically into Python26.dll/PythonNN.dll 
and compiled .PYD files, at least when using the Microsoft compiler.  

There has been a number of bugs related to the msvcrt.dll, 
msvcr90.dll, etc.  Many of these would go away if the CRT was 
statically linked into PythonNN.dll.  

The advantages of dynamically linking the CRT are not clear.  The 
binaries are decreased a bit in size, but this is countered by having 
to redistribute the CRT DLL.  

Switching to static linking is a little more work than just flipping a 
switch, as you have to compensate for some of the initialization work 
the DLL does, but it is both doable and worth doing.

----------
assignee: tarek
components: Distutils, Windows
messages: 92663
nosy: hankdane, tarek
severity: normal
status: open
title: Link CRT Statically
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Wed Sep 16 09:00:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 07:00:32 +0000
Subject: [issue6879] misstatement in example explanation using raise
In-Reply-To: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>
Message-ID: <1253084432.35.0.86508948984.issue6879@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, that seems a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6879>
_______________________________________

From report at bugs.python.org  Wed Sep 16 09:46:22 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 16 Sep 2009 07:46:22 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253087182.62.0.145147839784.issue6919@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This can't possibly work. Extension modules that also link with the CRT 
will thus end with a separate copy of the CRT global state, causing 
crashes.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Wed Sep 16 09:55:37 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 07:55:37 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1253087737.69.0.342653489746.issue6412@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Wed Sep 16 10:05:51 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 08:05:51 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1253088351.67.0.467796654975.issue6906@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I cannot reproduce it with the python.org version:

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.
py> import Tkinter
py> import os
py> os.environ['TK_LIBRARY']
'D:\\apps\\Python26\\tcl\\tk8.5'
py> any(isinstance(value,unicode) for value in os.environ.values())
False

This might be an ActiveState issue.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________

From report at bugs.python.org  Wed Sep 16 10:30:53 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 16 Sep 2009 08:30:53 +0000
Subject: [issue6920] IDLE 3 crashes on Ctrl+Space with "'utf8' codec can't
	decode bytes in position 0-1"
In-Reply-To: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za>
Message-ID: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

on Ubuntu 8.04 - 
I downloaded the sources, then:
./configure --prefix=$HOME
make && make install

in ~/bin/idle3 when I press Ctrl+Space (according to the "Edit" menu,
should show completions) idle crashes with the following traceback:
Traceback (most recent call last):
  File "/homes/yinon/bin/idle3", line 5, in <module>
    main()
  File "/homes/yinon/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/homes/yinon/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

----------
components: IDLE
messages: 92667
nosy: Yinon
severity: normal
status: open
title: IDLE 3 crashes on Ctrl+Space with "'utf8' codec can't decode bytes in position 0-1"
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6920>
_______________________________________

From report at bugs.python.org  Wed Sep 16 10:42:21 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 08:42:21 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1253090541.55.0.962499824883.issue6895@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

If you provide a test case the patch has a greater chance of being 
accepted.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6895>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:08:59 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 09:08:59 +0000
Subject: [issue6880] class needs forward reference
In-Reply-To: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za>
Message-ID: <1253092139.78.0.929182416484.issue6880@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6880>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:23:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 09:23:16 +0000
Subject: [issue6880] class needs forward reference
In-Reply-To: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za>
Message-ID: <1253092996.76.0.350383791689.issue6880@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, added a reference in r74818.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6880>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:25:05 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 09:25:05 +0000
Subject: [issue6876] readline documentation example error
In-Reply-To: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za>
Message-ID: <1253093105.01.0.181015655195.issue6876@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74819.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6876>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:31:05 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 09:31:05 +0000
Subject: =?utf-8?b?W2lzc3VlNjg5MV0gc21hbGwgdHlwbyBpbiDCq3VuaWNvZGUucnN0wrs6IMKr?=
	=?utf-8?q?the_Uniode_APIs_should_be_used=C2=BB_and_broken_URL?=
In-Reply-To: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>
Message-ID: <1253093465.45.0.600434109157.issue6891@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Commented out the link for now in r74820.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6891>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:34:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 09:34:45 +0000
Subject: [issue6881] incorrect signature in doc for PyByteArray_Resize
In-Reply-To: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>
Message-ID: <1253093685.48.0.787174325008.issue6881@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think the iterator type needs to be documented; many other such
iter types aren't.

Also, the argument names needn't match (since C doesn't have the notion
of keyword arguments).  They can be changed in the docs to be more
obvious than what the programmer chose :)

Would you like to fix the rest?

----------
assignee: georg.brandl -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6881>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:42:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 09:42:28 +0000
Subject: [issue6885] pdb documentation shows running as script using "python"
	not "python3"
In-Reply-To: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>
Message-ID: <1253094148.39.0.290295467004.issue6885@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74821.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6885>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:47:21 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 09:47:21 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1253094441.78.0.0545571312119.issue4749@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:52:25 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 09:52:25 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1253094745.87.0.48725210091.issue2320@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

@Robert: Yes, I'd say this is the same problem as issue4749

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:53:56 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 16 Sep 2009 09:53:56 +0000
Subject: [issue6829] Frendly error message when inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1253094836.36.0.578363507367.issue6829@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6829>
_______________________________________

From report at bugs.python.org  Wed Sep 16 11:56:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 09:56:03 +0000
Subject: [issue6903] pdb - print in for iteration prints None after printing
In-Reply-To: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za>
Message-ID: <1253094963.25.0.0519577336487.issue6903@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is caused by the special displayhook that pdb uses.

Normally, the displayhook suppresses output when it would print None;
this is not done in pdb's displayhook. This was a conscious decision,
because it can remove confusion when you try to get variable values like
this:

(Pdb) foo
(Pdb)

I'll ask python-dev for what is preferred.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6903>
_______________________________________

From report at bugs.python.org  Wed Sep 16 12:07:22 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Sep 2009 10:07:22 +0000
Subject: [issue6920] IDLE 3 crashes on Ctrl+Space with "'utf8' codec can't
	decode bytes in position 0-1"
In-Reply-To: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za>
Message-ID: <1253095642.3.0.611098879069.issue6920@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a duplicate of #1028.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6920>
_______________________________________

From report at bugs.python.org  Wed Sep 16 12:13:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 10:13:16 +0000
Subject: [issue5621] Add description of special case to "Assignment
	statements" section
In-Reply-To: <1238510706.85.0.278195682658.issue5621@psf.upfronthosting.co.za>
Message-ID: <1253095996.59.0.0328457416417.issue5621@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The patch submission was correct.

I edited the patch a bit, moved the example from augmented assignment to
the regular assignment and added a link from there to the new section.

Committed in r74822.

----------
resolution: works for me -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5621>
_______________________________________

From report at bugs.python.org  Wed Sep 16 13:40:10 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 16 Sep 2009 11:40:10 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1253101210.25.0.769207841797.issue1028@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Isn't this better implemented via a codec error handler?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed Sep 16 14:24:36 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Sep 2009 12:24:36 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253103876.13.0.452202720315.issue6844@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I agree that this is a release blocker for 2.6.3

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 14:48:16 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Sep 2009 12:48:16 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1253105296.6.0.404224279919.issue6851@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Agreed this should be a release blocker for 2.6.3

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________

From report at bugs.python.org  Wed Sep 16 14:48:56 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Sep 2009 12:48:56 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253105336.24.0.0123541574646.issue6918@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Agreed this should be a release blocker for 2.6.3

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Wed Sep 16 14:50:08 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Sep 2009 12:50:08 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253105408.07.0.630786142501.issue6864@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm willing to leave this as a release blocker for 2.6.3, but I will
re-evaluate it if no progress is made on it.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Sep 16 15:02:21 2009
From: report at bugs.python.org (Ask Solem)
Date: Wed, 16 Sep 2009 13:02:21 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1253106141.03.0.502516973596.issue5672@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Amaury Forgeot d'Arc, wrote:
  And I'd follow the same path: provide a way to build a launcher - 
  a .exe file that simply starts python with the given script.

Sounds good, but how would you expect to set the process name
for a subprocess, like a multiprocessing.Process? Make one shell script
for every process you want to launch and use exec? Maybe even dynamically 
create the scripts? This is not a solution.

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Sep 16 15:04:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 13:04:04 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1253106244.07.0.247848384435.issue6875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That one has to close open files should be common knowledge.

And it's already documented that the filehandle returned is to be
treated as if coming from `os.open`, so the "isn't a file object" is
documented as well.

Insofar, I'm in agreement with David.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6875>
_______________________________________

From report at bugs.python.org  Wed Sep 16 15:11:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 13:11:14 +0000
Subject: [issue6892] optparser example in optparse documentation is broken
In-Reply-To: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za>
Message-ID: <1253106674.33.0.614255005658.issue6892@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed (by adding the add_help_option=False argument to OptionParser) in
r74824.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6892>
_______________________________________

From report at bugs.python.org  Wed Sep 16 15:33:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Sep 2009 13:33:35 +0000
Subject: [issue6879] misstatement in example explanation using raise
In-Reply-To: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>
Message-ID: <1253108015.21.0.104692979755.issue6879@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74825 (trunk) and r74827 (release26-maint), thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6879>
_______________________________________

From report at bugs.python.org  Wed Sep 16 15:44:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 13:44:29 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253108669.21.0.0142650382762.issue6919@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Wed Sep 16 16:05:44 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 16 Sep 2009 14:05:44 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253109944.27.0.764423964262.issue6844@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I'm not sure I'll be able to work on this again for a while after this
morning, so here's a patch.  I don't really understand how the exception
structs are involved here, so I don't really know why the patch works,
but it seems to.  If there's something wrong with it, someone else may
need to fix it in order to have it ready for 2.6.3.

----------
keywords: +patch
Added file: http://bugs.python.org/file14896/less-deprecated-message.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 16:54:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Sep 2009 14:54:04 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1253112844.05.0.269316757259.issue6760@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We are trying to cut down on the number of "warning" directives in the
docs; I think a "note" directive would be appropriate for yours.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6760>
_______________________________________

From report at bugs.python.org  Wed Sep 16 17:33:38 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Sep 2009 15:33:38 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253115218.03.0.801340232787.issue1613573@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Yep, the patch at #6267 is an extension of this one except for the last 
chunk where I also check if sockets are ssl-enabled. I am not sure why 
it was needed. It also may have been already fixed somewhere else. As 
this bug doesn't have any tests attached it may be considered closed for 
now.

Would be nice to see these fixes in Python 2.6 though as it is the 
default version that seems to go in Ubuntu 9.10

+        import socket
+        if not socket._have_ssl:
             raise NotImplementedError(
                 "your version of httplib doesn't support HTTPS"
                 )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Wed Sep 16 17:35:14 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 16 Sep 2009 15:35:14 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1253115314.35.0.638299668716.issue5672@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> prctl is not portable. I always thought that the premise of stdlib is to
> provide portable interfaces.  BSD, for example, uses setprocname instead
> of prctl.  Also, prctl does not modify the process name shown in "ps
> uxww". Here's how PostgreSQL does this: http://tinyurl.com/mhjuqc.

Many parts of the stdlib are not portable.  It is perfectly appropriate
for the stdlib to expose a low-level, platform-specific API directly and
in a way which makes the Python API similarly low-level and non-portable.

That's not to say that a cross-platform API cannot *also* be provided,
though, assuming the functionality can be implemented *somehow* on other
platforms.  So I agree with Martin.  prctl should be exposed as-is.  If
someone would also like to expose similar functionality on on other
platforms, great.  And if someone would like to provide a cross-platform
API based on these, also great.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Sep 16 17:38:44 2009
From: report at bugs.python.org (David Hanney)
Date: Wed, 16 Sep 2009 15:38:44 +0000
Subject: [issue6921] recursion wierdness ... related to variable scoping?
In-Reply-To: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>
Message-ID: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>


New submission from David Hanney <spam2008 at nney.com>:

I was playing about with ideas behind b-plus-trees
and found i python bug

the important bit of code is:

            


            for p, k in enumerate(self.keys):
                self.ptrs[p].dump(indent+1, kmin=lk, kmax=k)
                print sindent + "(" + str(k) + ")"
                lk = k

            #
            # python bug?
            #
            show_python_bug = len(sys.argv)>1
            if show_python_bug:
                #
                # why not this?
                assert p == len(self.keys)-1
            else:
                #
                # why do I need this instead?
                p = len(self.keys)-1


i'm expecting k to still be in scope and equal len(self.keys)-1
sometimes it is and sometimes it isn't (depending on recursion depth)

you can try it for yourselves as I attach the full program:

./btree.py
runs fine
./btree.py  show_python_bug
eventually breaks like this:

Traceback (most recent call last):
  File "./btree.py", line 235, in <module>
    page.dump()
  File "./btree.py", line 223, in dump
    self.ptrs[p+1].dump(indent+1, kmin=lk)
  File "./btree.py", line 223, in dump
    self.ptrs[p+1].dump(indent+1, kmin=lk)
  File "./btree.py", line 223, in dump
    self.ptrs[p+1].dump(indent+1, kmin=lk)
  File "./btree.py", line 217, in dump
    assert p == len(self.keys)-1
UnboundLocalError: local variable 'p' referenced before assignment

... despite executing that code many times successfully before this
happens ... strange!

I hope you can figure it out and that this report proves helpful.

----------
components: Interpreter Core
files: btree.py
messages: 92691
nosy: mrdiskodave
severity: normal
status: open
title: recursion wierdness ... related to variable scoping?
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14897/btree.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6921>
_______________________________________

From report at bugs.python.org  Wed Sep 16 17:53:45 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Wed, 16 Sep 2009 15:53:45 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253116425.95.0.927269075073.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

The patch `readline-libedit.patch` has the following problems:

- a typo causing an undefined variable error;
- a missing "#endif";
- it doesn't refer to the new __APPLE__ specific doc string anywhere.

It fails to compile `readline.c`. ::

    Modules/readline.c:1073: error:
        ?using_libedit_emultation? undeclared (first use in this 
function)
    Modules/readline.c:1059:1: error: unterminated #ifdef

The fixed patch is attached as `readline-libedit-2.patch` above.
Please review it.

There are also a few minor stylistic nits I took a liberty to fix.

In readline.c
=============

Line 496
    Formatted a block comment to a usual C style (used by other comments
    it the patch, FWIW).

Line 505
    The standard style in C (and C-like) languages is to *not* write a
    space between a variable and a unary operator (e.g., "C++").
    Changed it to::

        idx--;

Lines 1085/86
    Removed two unnecessary empty lines added by the first patch.
    There's already one empty line in the original code to space an if
    statement from the next line.

Line 1070
    Line was longer than 79 characters (violates PEP-7).  Reformatted.


In setup.py
===========

Line 561
    A comment block was indented in the first patch and had lines longer
    than 79 characters (violates PEP-8).  I refactored the code to avoid
    repeating the same else statement twice.  This obviated the need to
    indent the said comment block.

    *Please review whether you agree with the refactoring*

Just out of curiosity: does anyone know why the first if statement that
tests for 'darwin' uses ``platform`` and the second one uses
``sys.platform``?  Couldn't we use ``platform`` in both of them?

----------
Added file: http://bugs.python.org/file14899/readline-libedit-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Wed Sep 16 18:02:13 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2009 16:02:13 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253116933.59.0.515024174024.issue1613573@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@techtonik: I don't think that testing socket._have_ssl is better than testing
for HTTPSConnection. socket._have_ssl might be True, whereas
HTTPSConnection is missing for a random reason. xmlrpclib uses
HTTPSConnection, not directly the socket library. HTTPSConnection may be
implemented using something else than socket / ssl.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Wed Sep 16 18:16:45 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 16 Sep 2009 16:16:45 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1253117805.93.0.111063144303.issue6873@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Martin,

Corrected the patch accordingly. Can you verify whether the fix is
correct or not now? 

Boya

----------
Added file: http://bugs.python.org/file14900/patch_6873.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6873>
_______________________________________

From report at bugs.python.org  Wed Sep 16 18:18:28 2009
From: report at bugs.python.org (darkspork)
Date: Wed, 16 Sep 2009 16:18:28 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253117908.46.0.0170338930075.issue6864@psf.upfronthosting.co.za>


darkspork <cjd.d01071 at gmail.com> added the comment:

I can confirm this as well. It also locks up when pasting text. The EDIT 
menu retains its glow, and the pasted text appears after a few seconds, 
along with another blank square window titled "idle". Idle then locks up. 
Using the scrollbar in any way (even by using the mousewheel) also locks 
up IDLE, although the window scrolls perfectly well.

----------
nosy: +darkspork

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Sep 16 18:24:17 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Sep 2009 16:24:17 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253118257.22.0.708362272556.issue1613573@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There should be a better way to do this check, because HTTPConnection 
method may exists, but HTTPConnection may be impossible, because of 
other reasons.

And I still would like to see this fix in Python 2.6 - too bad it hadn't 
enough attention before 2.6.

Flags like +wanted-2.6 like in FireFox bugzilla could really help to 
see/discuss critical parts to be included for everybody before it's too 
late. Should we stop development and dedicate a month or two on 
improving the process? =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Wed Sep 16 18:28:59 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 16 Sep 2009 16:28:59 +0000
Subject: [issue6903] pdb - print in for iteration prints None after printing
In-Reply-To: <1253094963.25.0.0519577336487.issue6903@psf.upfronthosting.co.za>
Message-ID: <26A2F4DC-2787-418D-BE58-9ECC12703ABE@acm.org>


Mitchell Model <mlm at acm.org> added the comment:

No problem with the None's -- I see your point about that. Just that  
maybe the alias example should point out that the Nones will be  
printed so people won't be surprised and try to figure out what's wrong.

     --- Mitchell

On Sep 16, 2009, at 5:56 AM, Georg Brandl wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> This is caused by the special displayhook that pdb uses.
>
> Normally, the displayhook suppresses output when it would print None;
> this is not done in pdb's displayhook. This was a conscious decision,
> because it can remove confusion when you try to get variable values  
> like
> this:
>
> (Pdb) foo
> (Pdb)
>
> I'll ask python-dev for what is preferred.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6903>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6903>
_______________________________________

From report at bugs.python.org  Wed Sep 16 18:36:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 16:36:53 +0000
Subject: [issue6903] pdb - print in for iteration prints None after printing
In-Reply-To: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za>
Message-ID: <1253119013.28.0.741677938409.issue6903@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Actually, Guido hates the Nones. :)  Fixed in r74839.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6903>
_______________________________________

From report at bugs.python.org  Wed Sep 16 19:09:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2009 17:09:59 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253120999.85.0.791096451401.issue1613573@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@techtonik: We wrote "HTTPConnection" twice. I don't really understand your
request. Do you think that the issue is fixed in Python trunk or not? If not,
please open a new issue since this issue is closed.

techtonik> And I still would like to see this fix in Python 2.6
techtonik> - too bad it hadn't enough attention before 2.6.

Python is developed for people working on Python in their free time. Vote for
an ticket is useless. If you want to see your fix faster in the subversion, follow
some rules:
 - explain correctly the issue
 - write a test
 - write a patch
 - explain your solution
 - fix your patches if needed after each patch review

You posted your patch the 2008-07-01, and the 2.6 final version was released
the 1st october. It was a little bit too late for the 2.6, but it may be included in
next 2.6.x release if it's easy to backport it. I also think that not enough people
are interested by XML-RPC + HTTPS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Wed Sep 16 19:10:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2009 17:10:25 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253121025.87.0.549543490021.issue1613573@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Wed Sep 16 19:13:02 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2009 17:13:02 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253121182.25.0.0812503394679.issue1613573@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@techtonik: You wrote "HTTPConnection" twice. I don't really understand your
request. Do you think that the issue is fixed in Python trunk or not? If not,
please open a new issue since this issue is closed.

techtonik> And I still would like to see this fix in Python 2.6
techtonik> - too bad it hadn't enough attention before 2.6.

Python is developed by people working on Python in their free time. IMHO,
voting for an ticket is useless. If you want to see your fix faster in the
subversion, follow some rules:
 - explain correctly the issue
 - write a test
 - write a patch
 - explain your solution
 - fix your patches if needed after each patch review

You posted your patch the 1st July 2008, and the 2.6 final version was released
the 1st october 2008. It was a little bit too late for the 2.6 (because of the
beta/RC releases), but it may be included in next 2.6.x release if it's easy to
backport it. I also think that not enough people are interested by XML-RPC +
HTTPS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Wed Sep 16 19:33:51 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Wed, 16 Sep 2009 17:33:51 +0000
Subject: [issue5483] [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache
	even when writeback=True
In-Reply-To: <1236949925.76.0.785103969967.issue5483@psf.upfronthosting.co.za>
Message-ID: <1253122431.32.0.490859693395.issue5483@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

If I understand you correctly, your proposal is the following: use
Shelf.cache to cache *all* objects instead of only keeping live
references. Your patch retains the cache forever instead of purging it
on sync. (All these changes only apply with writeback=True, which you
enabled by default; nothing changes with writeback=False.)
This speeds up *repeated* reads/writes as they are kept in-memory
instead of querying the-- probably slow --database every time.

I do not think this is a feasible solution for two reasons:
(1) writeback was never intended to do such thing. It was introduced as
a solution to "make shelve less surprising." If you remove its
sync-on-close characteristics, shelve is as surprising as before. See
issue553171.
(2) If you intend to implement caching on *any* database I'd suggest not
using shelve for that matter. Using it for serialization is all okay but
I'd rather add an additional layer of indirection to implement caching
strategies if you want to do that The Right Way. (Shelf.cache is really
only a map of objects that were touched during runtime.)

I'm -1 on this patch but generally +1 on a generic caching wrapper.

The error you describe later on appears because Python is already
tearing down when gc'ing the Shelf (calling __del__ -> close -> sync).
With writeback=True this currently tries to pickle the cache again which
emits the error you observed. This should be handled in a separate issue.

----------
nosy: +lehmannro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5483>
_______________________________________

From report at bugs.python.org  Wed Sep 16 19:38:16 2009
From: report at bugs.python.org (Alex)
Date: Wed, 16 Sep 2009 17:38:16 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>


New submission from Alex <malicious.wizard at gmail.com>:

*** Prerequisites:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32

*** Description:
'utf_32_le' and 'utf_32_be' codecs are overconsuming memory when input
data are damaged and kwarg 'errors' to str.decode is other than 'strict'.

*** Steps:
1. Start interpreter
2. Type:
   '\x01'.decode('utf_32_le', 'replace')
or
   '\x01'.decode('utf32', 'ignore')
or
   ('something'.encode('utf32') + '\x00').decode('utf32', 'ignore')
3. Execute

*** Notes:
1. seems like any stream raising UnicodeDecodeError in 'strict' mode
causes hangup in 'ignore' or 'replace'.

*** Expected result:
1. AssertionError on "assert errors == 'strict'" raised, just as
bz2_codec does, if utf32 cannot be partially decoded at all.
2. Behaviour that 'utf8' and 'utf16' implement for such cases.

*** Received result:
1. Interpreter hangs, uses up to 100% of CPU kernel and starts to
consume RAM.
2. Grows large enough to consume all the RAM it could get (takes up to
several minutes on my machine).
3. Produces following traceback:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python26\lib\encodings\utf_32_be.py", line 11, in decode
    return codecs.utf_32_be_decode(input, errors, True)
MemoryError
4. Sometimes traceback is printed, but text "MemoryError" is not, just
leaving blank line in the place.

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
messages: 92704
nosy: mwizard
severity: normal
status: open
title: Interpreter hangs up while trying to decode invalid utf32 stream.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Wed Sep 16 19:59:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 16 Sep 2009 17:59:50 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1253123990.33.0.626889794698.issue6873@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Yes, it looks correct now. I still wish it could be tested on a system 
where the problem actually occurs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6873>
_______________________________________

From report at bugs.python.org  Wed Sep 16 20:12:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Sep 2009 18:12:24 +0000
Subject: [issue6921] recursion wierdness ... related to variable scoping?
In-Reply-To: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>
Message-ID: <1253124744.31.0.893567805344.issue6921@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is almost certainly not a bug in Python.  At a guess, in the 
outermost 'else' clause of your dump method, self.keys can be empty.  Then 
the 'for p, k in enumerate(self.keys):' does zero iterations, so p is not 
defined in the assert;  hence the error message.

If you want help figuring out exactly what's going wrong, I'd suggest 
asking on comp.lang.python.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6921>
_______________________________________

From report at bugs.python.org  Wed Sep 16 20:22:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Sep 2009 18:22:39 +0000
Subject: [issue6921] recursion wierdness ... related to variable scoping?
In-Reply-To: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>
Message-ID: <1253125359.15.0.202381672279.issue6921@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, I see the problem now:  you're expecting that after

for p, elt in enumerate(mylist):
    <do_stuff>

p will be equal to len(mylist)-1.  That's true if mylist is nonempty 
(because on the last round of the for loop, p gets the value len(mylist)-
1), but if mylist is empty then no assignment to p or to elt is ever made.  
That's just the way that Python for loops work, I'm afraid.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6921>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:20:23 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 19:20:23 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253128823.21.0.655567178747.issue6844@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The patch leads to crashes with all the exceptions that have their own
structs; since they are derived from BaseException they must start with
the same binary layout as PyBaseExceptionObject (pointers to any
exception will be cast to PyBaseExceptionObject).

This also shows one way in which this change can mess up third-party
extensions (though I don't know if anybody does that): if some extension
created new exception classes doing it the way we do, e.g. for SyntaxError.

However, I have a different suggestion: we could put a user-set
"message" in the __dict__.  The getter would then check for that first
and only warn if it falls back to self->message. See attached patch.

----------
Added file: http://bugs.python.org/file14901/exception-message-fix-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:28:57 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 19:28:57 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253129337.11.0.580989213464.issue6844@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Huh. I just made some tests to find out if exceptions with a message set
survive pickling in 2.6.2 and unpickling in patched trunk.

I found that the message attribute isn't pickled at all in 2.6.2, so
there should be no cross-version compatibility problems with pickles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:38:36 2009
From: report at bugs.python.org (Alan Isaac)
Date: Wed, 16 Sep 2009 19:38:36 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253129916.31.0.503458477882.issue6844@psf.upfronthosting.co.za>


Alan Isaac <alan.isaac at gmail.com> added the comment:

I hope it is not too annoying to link these ...

I asked thhis of Jean-Paul but now I'll ask it of George.
Since you are working on this, can you see if 
http://bugs.python.org/issue6108 
is related or in any case can be fixed at the same time?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:41:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Sep 2009 19:41:16 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1253130076.26.0.42390916583.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch, with minor changes:
  - remove an incorrect Py_DECREF(str)
  - rename _PyLong_ToDecimal;  no need for the _Py prefix, since this
    function isn't shared across files
  - absorb special case for 0 into the rest of the code
  - whitespace and indentation fixes

Not that it matters much, but it's curious that on my machine (gcc-4.2, OS 
X 10.6.1, x64-64) it's significantly faster (~6% increase in str() speed 
for large integers) to use the line:

    pout[j] = z - (twodigits)hi * _PyLong_DECIMAL_BASE;

in the middle of the inner loop, rather than the line:

    pout[j] = z - hi * _PyLong_DECIMAL_BASE;

I'm wondering whether this is just a quirk of my OS/compiler combination, 
or whether there's a good reason for this difference.  The lines are 
functionally equivalent, since the result is reduced modulo 2**32 either 
way, but the first line involves a 32x32->64 multiplication and a 64-bit 
subtraction, where the second involves a 32x32->32 multiplication and a 
32-bit subtraction;  the generated assembly code for the second line is 
also one instruction shorter (there's a move opcode saved somewhere).

----------
Added file: http://bugs.python.org/file14902/long_decimal_conversion_py3k_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:41:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 19:41:33 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253130093.73.0.817840539867.issue6844@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, it should be fixed, but it is not related.  I'm setting it as a
release blocker as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:41:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 19:41:34 +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: <1253130094.46.0.0573476614597.issue6108@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Wed Sep 16 21:59:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 19:59:18 +0000
Subject: [issue6890] IOError has no __unicode__ method - and loses information
In-Reply-To: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za>
Message-ID: <1253131158.18.0.858654766736.issue6890@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And this is a duplicate of (the somewhat complicated-named) #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/issue6890>
_______________________________________

From report at bugs.python.org  Wed Sep 16 22:01:32 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Sep 2009 20:01:32 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253131292.8.0.475950298543.issue6844@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just looked at the patch and it looks good to me. I say go ahead and 
commit, Georg.

----------
assignee: loewis -> georg.brandl
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 22:03:14 2009
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 16 Sep 2009 20:03:14 +0000
Subject: [issue6923] Need pthread_atfork-like functionality in CPython
In-Reply-To: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za>
Message-ID: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za>


New submission from Thomas Wouters <thomas at python.org>:

In order to properly handle multiple threads and fork()-calls from C code 
(rather than os.fork()), Python should provide pthread_atfork()-like 
functionality: a function to call before a fork, to acquire any locks 
that need to be acquired, and a pair of functions to call after the fork, 
in the parent and the child, to release or re-allocate locks. The 
acquisitions should be re-entrant and should not require an existing 
threadstate. Also see <http://bugs.python.org/issue1590864>.

----------
assignee: twouters
components: Interpreter Core
messages: 92715
nosy: twouters
priority: low
severity: normal
stage: needs patch
status: open
title: Need pthread_atfork-like functionality in CPython
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6923>
_______________________________________

From report at bugs.python.org  Wed Sep 16 22:04:07 2009
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 16 Sep 2009 20:04:07 +0000
Subject: [issue1590864] Function-level import in os triggering an threaded
	import deadlock
Message-ID: <1253131447.34.0.628135584669.issue1590864@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Checked in the patch to fix the forks-through-os.fork() cases, which 
should be most of them. Forks from other C code will need some more work, 
created http://bugs.python.org/issue6923 to track that.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1590864>
_______________________________________

From report at bugs.python.org  Wed Sep 16 22:25:20 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Sep 2009 20:25:20 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253132720.01.0.606356755452.issue6918@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Annoyingly PyObjC suffers from the same issue. I hadn't noticed this yet 
because I've been linked to the system copy of libffi the last couple of 
months.

Luckily Apple has already released the source code for libffi in 10.6 
(see http://www.opensource.apple.com/source/libffi/libffi-15/, or 
http://www.opensource.apple.com/tarballs/libffi/libffi-15.tar.gz). 

Next steps:
* Check diffs between this release and the one in ctypes
* Update ctypes libffi_osx based on those differences
* Test the result on 10.5 and 10.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Wed Sep 16 22:35:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Sep 2009 20:35:24 +0000
Subject: [issue6844] BaseException DeprecationError raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1253133324.86.0.612988164877.issue6844@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I added another test for pickling, committed in r74845, and
backported to 2.6 in r74848.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________

From report at bugs.python.org  Wed Sep 16 22:51:29 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 16 Sep 2009 20:51:29 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253134289.89.0.352375961149.issue6864@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

The bug with the edit menu sounds like the same issues I noted in 
http://bugs.python.org/issue6463. I think it was related to something in 
Tk-Cocoa 8.5, which was resolved in a later build of Tk, and which is why 
I closed the bug. The build of Tk-Cocoa that ships with Snow Leopard may 
have preceded the bug fix (there has been a lot of activity on the Tk-
Cocoa front in recent weeks). If that's the case, I doubt a fix will be 
available unless Apple updates its core Tk libraries. The best workaround 
might be to install an updated build from the source 
http://github.com/das/tcltk/tree/de-carbon-8-5 into /Library/Frameworks.

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Sep 16 23:35:58 2009
From: report at bugs.python.org (Travis H.)
Date: Wed, 16 Sep 2009 21:35:58 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253136958.98.0.547921148572.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

I have coded up a first draft at implemented {get,set}res{gid,uid}
functions.  This completes the exposure of the user and group setting
functions, and enables python programmers to be able to safely drop
privileges, for example when running network daemons as root that need
to drop down to user privileges, or writing a setuid program which needs
to do the same.

I cannot test this in my current environment because I'm stuck with Red
Hat and it does not have a recent enough automake to re-create configure
from configure.in.

----------
versions: +Python 2.6 -Python 3.2
Added file: http://bugs.python.org/file14903/foo.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Wed Sep 16 23:42:35 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Sep 2009 21:42:35 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1253137355.94.0.794115785548.issue6851@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch seems to fix the issue, but needs further testing. 

Warning: the patch is not entirely clean, the patch contains an 
unrelated change to setup.py.

The patch replaces some code that uses ctypes to read configuration data 
using the SystemConfiguration framework by a regular extension. 

With this patch the crasher goes away, I still have to do more testing 
and proper checking of the C code.

The patch is for the trunk, I expect it will cleanly port to 2.6. It 
will also need porting to 3.x later on.

----------
keywords: +26backport, patch
Added file: http://bugs.python.org/file14904/urllib-crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________

From report at bugs.python.org  Wed Sep 16 23:45:01 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Sep 2009 21:45:01 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253137501.36.0.22658122233.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

kevin: do you know if there is a plain Tcl script that shows the bug? If 
there is we can file a bugreport with Apple that clearly shows a problem 
in the Tk framework and hence makes it more likely that the issue will get 
fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Sep 16 23:52:36 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 16 Sep 2009 21:52:36 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253137956.0.0.216855065082.issue6864@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Ronald: No, unfortunately I was never able to reproduce the bug in pure 
Tcl. I tried various examples with the Tk text widget. I also tried 
various examples with the text widget via Tkinter. Each time the text 
widget, cutting, pasting, etc. worked as expected. I suspect the bug is 
somewhere in IDLE's interaction with that iteration Tk-Cocoa, but I could 
not pinpoint it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Sep 16 23:53:20 2009
From: report at bugs.python.org (Emmanuel Bengio)
Date: Wed, 16 Sep 2009 21:53:20 +0000
Subject: [issue6924] struct.unpack weird behavior with "bi" (byte then integer)
In-Reply-To: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za>
Message-ID: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za>


New submission from Emmanuel Bengio <bengioe at gmail.com>:

Using the following command in Python 2.6.1:

>>> struct.unpack("BI","12345")
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    struct.unpack("BI","12345")
error: unpack requires a string argument of length 8

I get this error message. What confused me was that doing
>>> struct.unpack("IB","12345")
(875770417, 53)
Worked just fine.

I have found out that this only happens using the native byte
order("@"), which is the default.
For Example:
>>> struct.unpack("!BI","12345")
(49, 842216501)
Works, and all other variants, =, <, > (native standard,little endian,
and small endian) also do.

I haven't found anything about that in the documentation.

Also, the requested 3 other bytes arent event used:
>>> struct.unpack("I","abcd")
(1684234849,) # see the big number starting with 16
>>> ord("x")
120
>>> struct.unpack("BI","xabcd") # we get the error
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    struct.unpack("BI","xabcd")
error: unpack requires a string argument of length 8
>>> struct.unpack("BI","xabcdefg")
(120, 1734763876) # not the same here
>>> struct.unpack("BI","xabcabcd")
(120, 1684234849) # same here
>>> struct.unpack("BI","x___abcd")
(120, 1684234849) # same again

----------
components: Library (Lib)
messages: 92724
nosy: Manux
severity: normal
status: open
title: struct.unpack weird behavior with "bi" (byte then integer)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6924>
_______________________________________

From report at bugs.python.org  Thu Sep 17 00:05:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Sep 2009 22:05:55 +0000
Subject: [issue6924] struct.unpack weird behavior with "bi" (byte then integer)
In-Reply-To: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za>
Message-ID: <1253138755.55.0.428332068397.issue6924@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this is expected behaviour:  the key point is that structs can 
include padding bytes.  From the documentation:

"By default, C numbers are represented in the machine?s native format and 
byte order, and properly aligned by skipping pad bytes if necessary 
(according to the rules used by the C compiler)."

'Native' struct formats include padding, while 'standard' formats don't.

So a native struct with format 'BI' has one byte for the 'B', followed by 
3 padding bytes, followed by four bytes for the 'I'.  This exactly matches 
the way a C struct of the form {char c; int x;} would be organized in 
memory on that machine.

----------
assignee:  -> marketdickinson
nosy: +marketdickinson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6924>
_______________________________________

From report at bugs.python.org  Thu Sep 17 00:23:06 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 16 Sep 2009 22:23:06 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253139786.19.0.639650071605.issue6508@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> I cannot test this in my current environment because I'm stuck with Red
> Hat and it does not have a recent enough automake to re-create configure
> from configure.in.

FWIW, it may be an _autoconf_ version issue; I'm able to recreate a
"configure" from Python's "configure.in" on my RHEL5 box by downloading
autoconf-2.61 from http://ftp.gnu.org/gnu/autoconf/
installing it to /usr/local (with ./configure ; make; sudo make install)
then invoking /usr/local/bin/autoconf in the root of an SVN checkout of
python.   Hope this is helpful.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Thu Sep 17 00:24:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Sep 2009 22:24:27 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1253139867.85.0.262044555401.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied long_decimal_conversion_py3k_2.patch in r74851;  backported to 
trunk in r74853.

Still to do:
 - look at the 'two-digits-at-a-time' optimization.
 - rip out the non-binary-base code from _PyLong_Format

While we're at it, it would also be good to look at the decimal string -> 
integer conversion,  but I think that's a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Thu Sep 17 00:58:52 2009
From: report at bugs.python.org (David Hanney)
Date: Wed, 16 Sep 2009 22:58:52 +0000
Subject: [issue6921] recursion wierdness ... related to variable scoping?
In-Reply-To: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>
Message-ID: <1253141932.4.0.384647383504.issue6921@psf.upfronthosting.co.za>


David Hanney <spam2008 at nney.com> added the comment:

Ooops. I'm just learning Python and it never occurred to me that I could
get through the for without k begin defined. At least not until about an
hour ago in the cinema. I came here ASAP but you'd already got to it.
Sorry for wasting your time.

I should have spent more time boiling down a concise test case then I
could have seen this for myself BEFORE posting. Once again, apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6921>
_______________________________________

From report at bugs.python.org  Thu Sep 17 01:18:06 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 Sep 2009 23:18:06 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

It appears that somewhere between Python 2.5 and Python 2.6, some socket
constants were lost in Windows builds.

Python 2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket; socket.IPPROTO_IPV6
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'IPPROTO_IPV6'

Confirmed this problem on 32-bit builds and Python 3.1.1 also. I suspect
the compiler upgrade influenced this behavior.

Let me know if I can help track down the issue.

----------
components: IO, Windows
messages: 92730
nosy: jaraco
severity: normal
status: open
title: socket module missing IPPROTO_IPV6, IPPROTO_IPV4
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Thu Sep 17 00:54:42 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 22:54:42 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Doc for locals(): after correctly stating
"Update and return a dictionary representing the current local symbol table.

Note
The contents of this dictionary should not be modified; changes may not
affect the values of local variables used by the interpreter."

current doc goes on to say
"Free variables are returned by locals() when it is called in a function
block. Modifications of free variables may not affect the values used by
the interpreter. Free variables are not returned in class blocks."

As best I can understand this, it is wrong and should be removed. Free
variables within a function block are global/nonlocal names and by my
experimentation with 3.1, (including lambda expressions) are NOT
returned by locals(). If it means something else, it needs a rewrite.

The doc for var() starts "Without arguments, return a dictionary
corresponding to the current local symbol table." I suggest augmenting
this with 'update and ' (to match locals doc) and '(same as locals())'
to make that fact clear (as it is with help(vars)), even though removing
the 'Free variables' stuff will help the latter clearer also. The result
would be

Without arguments, update and return a dictionary corresponding to the
current local symbol table (same as locals()).

----------
messages: 92728
nosy: tjreedy
severity: normal
status: open
title: Doc for locals and vars
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Thu Sep 17 01:21:17 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 Sep 2009 23:21:17 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1253143277.08.0.648388701864.issue6926@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This comment from the MSDN docs may be relevant:

On the Microsoft Windows Software Development Kit (SDK) released for
Windows Vista and later, the organization of header files has changed
and IPPROTO_IPV6 level is defined in the Ws2def.h header file which is
automatically included in the Winsock2.h header file. The IPPROTO_IPV6
socket options are defined in the Ws2ipdef.h header file which is
automatically included in the Ws2tcpip.h header file. The Ws2def.h and
Ws2ipdef.h header files should never be used directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Thu Sep 17 01:24:00 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 23:24:00 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1253143440.29.0.336807621621.issue1294232@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Thu Sep 17 01:33:33 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 23:33:33 +0000
Subject: [issue6927] Metaclass doc (Ref 3.3.3) errors
In-Reply-To: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za>
Message-ID: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

3.3.3. Customizing class creation
3.1/3.2 docs say
"If the metaclass keyword argument is based with the bases, it is used."
(new version for 3.x) I presume 'based' was meant to be 'passed'.

However, with that correction, would it really be correct?
I presume the metaclass compatibility issue discussed in #1294232 for
2.x is still relevant for 3.x.

The next line
"Otherwise, if there is at least one base class, its metaclass is used."
(same as for 2.x docs) does not say which 'its' is used if there is more
than one. See paragraph above and #1294232.

I do not know the actual rule well enough to improve the neglected
suggestion in the referenced issue.

----------
assignee: georg.brandl
components: Documentation
messages: 92732
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Metaclass doc (Ref 3.3.3) errors
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6927>
_______________________________________

From report at bugs.python.org  Thu Sep 17 01:53:49 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 23:53:49 +0000
Subject: [issue6928] Doc:  Class statements and metaclass = xxx
In-Reply-To: <1253145229.65.0.267557560742.issue6928@psf.upfronthosting.co.za>
Message-ID: <1253145229.65.0.267557560742.issue6928@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

For 3.x, I think 7.7 Class Definitions should mention the metaclass
keyword arg and cross-reference 3.3.3 Customizing class creation. Since
it is no longer a 'special' name, let alone a 'special method name',
there is no reason to know to look for it under that heading (I didn't
until I looked for 'metaclass' in the index, which I had to know to look
for, of course).

A possible sentence after "The class name is bound to this class object
in the original local namespace." (and before discussion of @classdeco)

"To modify this process, add 'metaclass = xxx' to the list of bases and
see CCustomizing class creation." with the last three words being a blue
link to 3.3.3.

2.x would need something a bit different, or just less ;-)

----------
assignee: georg.brandl
components: Documentation
messages: 92733
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Doc:  Class statements and metaclass = xxx
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6928>
_______________________________________

From report at bugs.python.org  Thu Sep 17 02:04:21 2009
From: report at bugs.python.org (Yuv Gre)
Date: Thu, 17 Sep 2009 00:04:21 +0000
Subject: [issue6905] inspect.getargspec(print) fails
In-Reply-To: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>
Message-ID: <1253145861.61.0.412723101964.issue6905@psf.upfronthosting.co.za>


Yuv Gre <ubershmekel at gmail.com> added the comment:

You're right, I was confused by the statement "arg is not a Python 
function". I didn't realize 'arg' meant the function I passed to 
getargspec, I thought it was just strange.

After digging a bit into inspect.py, may I suggest line 814 be changed 
from:
raise TypeError('arg is not a Python function')

to:
raise TypeError('%s is not a Python function' % func)

That way the error I would have received would have given:
TypeError: <built-in function print> is not a Python function

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6905>
_______________________________________

From report at bugs.python.org  Thu Sep 17 02:09:13 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Sep 2009 00:09:13 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1253146153.23.0.981595398228.issue6926@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I think I found the problem.

It appears Python is compiled with 

#define _WIN32_WINNT 0x0500

But IPPROTO_IPV6 (and other constants) are only defined

#if(_WIN32_WINNT >= 0x0501)

What's the proper fix for this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Thu Sep 17 02:15:11 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Sep 2009 00:15:11 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1253146511.28.0.515532526823.issue6926@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I think a suitable test case for this issue is:

if hasattr(sys, 'getwindowsversion'):
  if sys.getwindowsversion() >= (5,1):
    assert hasattr(socket, 'IPPROTO_IPV6')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Thu Sep 17 03:03:58 2009
From: report at bugs.python.org (Jeff Bradberry)
Date: Thu, 17 Sep 2009 01:03:58 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253149438.99.0.0885469241161.issue6300@psf.upfronthosting.co.za>


Jeff Bradberry <jeff.bradberry at gmail.com> added the comment:

This patch adds the requested behavior to the current 2.7 svn trunk. 
Both 'encoding' and 'errors' may be used as keyword arguments for
encode() and decode().

----------
keywords: +patch
nosy: +jbradberry
Added file: http://bugs.python.org/file14905/python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 03:59:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Sep 2009 01:59:58 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253152798.43.0.450767405851.issue6300@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

They should also probably be added to unicode(), str(), unicode.decode,
and unicode.encode then. (Also some tests, please!)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 04:55:03 2009
From: report at bugs.python.org (Henri Hein)
Date: Thu, 17 Sep 2009 02:55:03 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253156103.95.0.759308995146.issue6919@psf.upfronthosting.co.za>


Henri Hein <henri at granitetower.net> added the comment:

If you do not *want* to change it, that is your prerogative, but it 
*can* definitely work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Thu Sep 17 07:53:24 2009
From: report at bugs.python.org (Zhigang Wang)
Date: Thu, 17 Sep 2009 05:53:24 +0000
Subject: [issue5483] [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache
	even when writeback=True
In-Reply-To: <1236949925.76.0.785103969967.issue5483@psf.upfronthosting.co.za>
Message-ID: <1253166804.13.0.555781120113.issue5483@psf.upfronthosting.co.za>


Zhigang Wang <w1z2g3 at gmail.com> added the comment:

Thanks Robert for pointing out issue553171. 

After read that issue, I still think we paid too much to make shelf less
surprising.

We should at lease provide a option for the *smart* programmers to get
better speed and less exceptions.

The write-back-all-cache-on-close feature is easy to document, but hard
to accept when you have cached too much data.

CCing Alex and Martin for comments.

----------
nosy: +aleax, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5483>
_______________________________________

From report at bugs.python.org  Thu Sep 17 08:04:24 2009
From: report at bugs.python.org (Jeff Bradberry)
Date: Thu, 17 Sep 2009 06:04:24 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253167464.0.0.197830525262.issue6300@psf.upfronthosting.co.za>


Jeff Bradberry <jeff.bradberry at gmail.com> added the comment:

As it turns out, someone had previously made this adjustment to str()
and unicode().  My updated patch adds this behavior to unicode.decode
and unicode.encode, adds a couple of tests to test_unicode.py, and
updates the documentation to show that these functions (and str.format,
which had failed to be noted as taking them) now take keyword arguments.

----------
Added file: http://bugs.python.org/file14906/python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 09:49:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 07:49:45 +0000
Subject: [issue6912] Add 'with' block support to Tools/Scripts/pindent.py
In-Reply-To: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za>
Message-ID: <1253173785.51.0.569816100007.issue6912@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r74865.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6912>
_______________________________________

From report at bugs.python.org  Thu Sep 17 09:51:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 07:51:18 +0000
Subject: [issue6915] os.listdir inconsistenly releases the GIL on win32
In-Reply-To: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za>
Message-ID: <1253173878.06.0.386077921029.issue6915@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/issue6915>
_______________________________________

From report at bugs.python.org  Thu Sep 17 10:08:32 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 17 Sep 2009 08:08:32 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253174912.12.0.266420414165.issue6300@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The patch looks fine, the idea is good as well.

I'm just a little worried about the performance impact this might have
(not much though).

Could you run a quick comparison of before applying the patch compared
to after the patch is applied, using positional arguments in both cases ?

Thanks.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 10:12:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 17 Sep 2009 08:12:46 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253175166.21.0.948325352255.issue6508@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please do try this out on your system. Installing autoconf locally is 
really not difficult: download 2.61, then do

./configure --prefix=$HOME/ac261
make
make install

This will give you $HOME/ac261/bin/auto{conf|header}; automake is not 
needed for Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Thu Sep 17 10:17:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 17 Sep 2009 08:17:53 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253175473.93.0.186193753898.issue6508@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Your patch looks right, although I have a few style issues:
- the if chaining looks complicated: we don't usually have an else when 
the if returns
- make sure you use tabs consistently with the rest of the file
- it may be better to use uid_t where appropriate, see issue6873

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Thu Sep 17 10:50:49 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Sep 2009 08:50:49 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253177449.93.0.636464370816.issue6919@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It will seem to work for simple scripts, but many extension modules
won't behave properly because:
- some API functions (PyFile_AsFile, many PyRun_*functions,
PyMarshal_*+FromFile) pass FILE* structures, which differ between
instances of the CRT.
- file descriptors, environment variables, locale settings, the errno
variable, are not shared.
- when a thread exits, it would have to free thread-local storage for
each CRT.

Python uses Ansi C, and has to use the same system as the extension
modules it wants to support. Linking statically with the CRT may be a
solution in specific cases, but not for the general python distribution.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Thu Sep 17 11:15:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Sep 2009 09:15:57 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253178957.55.0.809345883996.issue6877@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Do the remove_history_item and replace_history_item functions also need 
the off-by-one adjustment?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Thu Sep 17 11:17:55 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Sep 2009 09:17:55 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253179075.72.0.751881900446.issue1613573@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This bug may be fixed. Unfortunately I do not possess original setup 
anymore. The primary issue is still issue648658 and that affects bzr + 
launchpad integration, XML-RPC access to bugzilla and probably more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Thu Sep 17 11:20:05 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Sep 2009 09:20:05 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1253179205.46.0.838954679855.issue1613573@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

And I want to add that I am glad that is finally fixed, so I really 
appreciate the work people done in this direction in their free time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Thu Sep 17 11:30:43 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 17 Sep 2009 09:30:43 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253179843.94.0.219991543658.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Mark: yes those functions need to be changed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Thu Sep 17 11:51:52 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 17 Sep 2009 09:51:52 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

It seems the properties of the write methods of these two classes are
mixed up in documentation. I've checked the sources, and actually it
seems the behviour is inverted :
rawiobase streams, which can be pipes or other limited streams, may
write less than len(b) bytes in one operation, and return ; whereas
rawfileio instances, which write on disk, will never fail writing all
the data unless the disk is full (resulting in IOError). It's rawiobase
which does one system call, not rawiofile which will try again until all
is written, isn't it ?

RawIoBase
write(b)
    Write the given bytes or bytearray object, b, to the underlying raw
stream and return the number of bytes written (never less than len(b),
since if the write fails an IOError will be raised).
    A BlockingIOError is raised if the buffer is full, and the
underlying raw stream cannot accept more data at the moment.


RawFileIO :
write(b)
    Write the bytes or bytearray object, b, to the file, and return the
number actually written. Only one system call is made, so it is possible
that only some of the data is written.

----------
assignee: georg.brandl
components: Documentation
messages: 92751
nosy: georg.brandl, pakal
severity: normal
status: open
title: Confusion between "write" method of rowiobase and rawfileio
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 12:04:54 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 10:04:54 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1253181894.75.0.264012197718.issue6922@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This patch fixes it (seems like a refactoring oversight, I used the
UTF16 decoder for reference, where it works fine) and adds a test,
assigning to MAL for review.

Marking as a release blocker so that 2.6.3 won't get released without a fix.

----------
assignee:  -> lemburg
keywords: +patch
nosy: +georg.brandl, lemburg
priority:  -> release blocker
resolution:  -> accepted
stage:  -> patch review
type:  -> crash
versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14907/fix-utf32-errorhandling.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Thu Sep 17 12:11:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 10:11:34 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253182294.63.0.932738304575.issue6929@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 12:12:59 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Sep 2009 10:12:59 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1253182379.52.0.143438391776.issue2517@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/issue2517>
_______________________________________

From report at bugs.python.org  Thu Sep 17 12:18:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 10:18:32 +0000
Subject: [issue6883] OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
Message-ID: <1253182712.81.0.920592301599.issue6883@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The (en|dis)able_interspersed_args accessors are already documented, so
I see no reason to document the attribute as well...

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6883>
_______________________________________

From report at bugs.python.org  Thu Sep 17 12:23:36 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 17 Sep 2009 10:23:36 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1253183016.0.0.61972639696.issue6922@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The patch looks good. Thanks.

Aside: This is what you get when using too many single character
variable names in a function...

The function should really do just one cast to (unsigned char *) at the
very top and then work with that variable all along.

----------
assignee: lemburg -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:07:23 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Sep 2009 11:07:23 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1253185643.75.0.630534241994.issue6860@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

To be able to do this fix, I also need to change the way commands are
registered in Distutils.

Right now, Distutils scans packages that were provided as "command
packages" and just adds all commands from the namespace, using the class
name. Which means there's no way to provide a command this way that is
not using something else than the class name.

To make it better I will introduce an explicit registration mecanism,
where a specific mapping will have to be provided in the package,
instead of looking directly for "pkgname.command", which is not very
handy from a developer point of view. (this behavior will be deprecated
but will still be used as the last way to register a command)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:08:31 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Sep 2009 11:08:31 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1253185711.17.0.249850313955.issue6516@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:09:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Sep 2009 11:09:30 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1253185770.89.0.623864571958.issue1180@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> accepted
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:09:57 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Sep 2009 11:09:57 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1253185797.34.0.352292220021.issue1180@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:11:00 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Sep 2009 11:11:00 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1253185860.0.0.381645919617.issue3984@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
priority:  -> low
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:13:54 2009
From: report at bugs.python.org (S Arrowsmith)
Date: Thu, 17 Sep 2009 11:13:54 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253186034.82.0.463365385011.issue6925@psf.upfronthosting.co.za>


Changes by S Arrowsmith <siona at chiark.greenend.org.uk>:


----------
nosy: +siona

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:17:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Sep 2009 11:17:04 +0000
Subject: [issue793069] Add --remove-source option
Message-ID: <1253186224.54.0.403468814884.issue793069@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> accepted
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue793069>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:33:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 11:33:40 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1253187220.55.0.711826844732.issue6922@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm leaving a refactoring to someone with more time :)

Committed in r74869, backported to 2.6 in r74870.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:43:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Sep 2009 11:43:07 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253187787.0.0.193794523526.issue6929@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hm, first, which version of the documentation are you looking at?
For the new IO lib, you should probably refer to the current py3k docs:
http://docs.python.org/py3k/library/io.html

Then, the documentation looks confused indeed. But your interpretation
is a bit confused as well ;)

RawIOBase is only an abstract base class, it doesn't provide any
meaningful implementation. The doc for write() here is wrong when it
says "... return the number of bytes written (This is never less than
len(b), since if the write fails, an IOError will be raised)". FileIO,
which is an implementation of RawIOBase (see below), *can* return less
than len(b).

FileIO (not RawFileIO, which doesn't exist) is an implementation of
RawIOBase. Its write() method does only one system call and does not try
to consume all of the input. Therefore, it can return less than the
length of the input string, particularly if the underlying file is in
non-blocking mode. It will return None if in non-blocking mode and *no*
byte of input has been consumed (this is to distinguish from the case
where the input would have been a 0-byte string). It will raise an
IOError in all other error cases.

However
-------

In daily life, most uses of FileIO will be wrapped in a BufferedWriter,
BufferedReader or BufferedRandom object (this is what happens if you use
the builtin open()). These classes *will* retry when write() is called,
until everything is written out or an error occurs.

The only exception is if the underlying file is in non-blocking mode, in
which case write() might raise a BlockingIOError if it couldn't write
everything without blocking.

Bottom line: write() on a *buffered* IO object (not a *raw* one) will
either write everything, or raise an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 13:45:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Sep 2009 11:45:48 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253187948.07.0.979020086883.issue6929@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I might add, in case it wasn't clear, that you will only encounter a raw
IO object (rather than a buffered one) if you construct one directly, or
if you give "buffering=0" to open().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 14:27:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 12:27:46 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253190466.42.0.716334184738.issue6925@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Free variables *are* returned by locals().  (Note that globals *aren't*
free variables.)  For example, try this:

def f():
  x = 1
  def g():
    print locals()
  g()
f()

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Thu Sep 17 14:27:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 12:27:53 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253190473.57.0.616259214087.issue6925@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Thu Sep 17 14:31:31 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Sep 2009 12:31:31 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253190691.58.0.201486232925.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch looks okay to me, and solves the issue on my Fedora box.

But perhaps a context manager in a "with" block would be clearer? I've
attached a patch.

----------
Added file: http://bugs.python.org/file14908/issue6882-contextlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 15:09:18 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 17 Sep 2009 13:09:18 +0000
Subject: [issue5754] Shelve module writeback parameter does not act as
	advertised
In-Reply-To: <1239728605.41.0.419145925815.issue5754@psf.upfronthosting.co.za>
Message-ID: <1253192958.72.0.854180767169.issue5754@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I think you're misquoting Python's shelve module documentation in your
first sentence. The documentation says:
"By default modified objects are written only when assigned to the shelf
[...]. If the optional writeback parameter is set to True, all entries
accessed are cached in memory, and written back at close time [...]."

The emphasis should be on the word "only:" it does *always* write to the
database when assigned to the shelf but, iff writeback=True, *also* to
the cache.

Also consider the consequences of *only* caching keys:
(a) __contains__ and has_key have to consult the dict and the cache for
membership tests.
(b) keys and __len__ need to compute a union of both sources.
(c) __delitem__ is no longer guaranteed to fail on the cache if it
failed for the database.

I admit the docs could spell this out more clearly. I attached a patch
ensuring the behaviour I described in a test and updating the docs.

(Note: shelve is no extension module -- it's part of the stdlib. Patch
applies to 3.x as well.)

----------
components: +Library (Lib) -Extension Modules
keywords: +patch
nosy: +lehmannro
Added file: http://bugs.python.org/file14909/issue5754.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5754>
_______________________________________

From report at bugs.python.org  Thu Sep 17 15:24:46 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 17 Sep 2009 13:24:46 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253193886.05.0.645368531654.issue6882@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Since ctypes should stay compatible with Python versions down to 2.4, a
"with" block cannot be used.

Of course would closing the object returned by os.popen() explicitely be
better style, but I wonder what the real problem is.  My observations so
far:

- The bug doesn't happen with Python 2.X, only with 3.X.
- If I assign the result of os.popen() to a local variable, _without_
closing it explicitely, the bug also doesn't happen (tested on Ubuntu).

I really wonder what's going on here...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 15:27:50 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 17 Sep 2009 13:27:50 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1253194070.67.0.896814449351.issue6729@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Would you like to work on a patch?

----------
versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Thu Sep 17 15:31:18 2009
From: report at bugs.python.org (Radim Novotny)
Date: Thu, 17 Sep 2009 13:31:18 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253194278.8.0.448594947965.issue6918@psf.upfronthosting.co.za>


Changes by Radim Novotny <novotny.radim at gmail.com>:


----------
nosy: +naro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Thu Sep 17 16:09:59 2009
From: report at bugs.python.org (Jon Foster)
Date: Thu, 17 Sep 2009 14:09:59 +0000
Subject: [issue6930] [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param)
In-Reply-To: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za>
Message-ID: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za>


New submission from Jon Foster <jon.foster at cabot.co.uk>:

The documentation for the C API function PyUnicode_DecodeUTF16() does
not match the code.

If *byteorder is 1 or -1, the documentation says that the function looks
for a BOM.  It doesn't.  This patch updates the documentation to match
the code.

(Also, I just realised that the docs for PyUnicode_DecodeUTF32() have
the exact same bug.  That is NOT fixed by this patch).

This patch also clarifies the PyUnicode_EncodeUTF16() docs.

----------
assignee: georg.brandl
components: Documentation
files: unicodedocs.patch
keywords: patch
messages: 92764
nosy: JonFoster, georg.brandl
severity: normal
status: open
title: [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14910/unicodedocs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6930>
_______________________________________

From report at bugs.python.org  Thu Sep 17 16:24:11 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Sep 2009 14:24:11 +0000
Subject: [issue6923] Need pthread_atfork-like functionality in CPython
In-Reply-To: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za>
Message-ID: <1253197451.88.0.870858849251.issue6923@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

For reference, this is related to http://bugs.python.org/issue6721 but 
deals with the C API side of things for an atfork mechanism to be used by 
extension modules.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6923>
_______________________________________

From report at bugs.python.org  Thu Sep 17 16:25:19 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Sep 2009 14:25:19 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1253197519.81.0.190796310211.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

issue 6923 has been opened to provide a C API for an atfork mechanism for 
use by extension modules.

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Sep 17 16:31:05 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Sep 2009 14:31:05 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253197865.52.0.213706367987.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The py3k version of the file already contains 3.x only code, and it's
missing the comment at the top that it should be compatible. But it's
not really a big deal to me.

The py3k version also already has some try/finally logic on some popen
calls that the trunk version doesn't, so I suspect this was a known
problem that was addressed, and this case was missed or added later.

<research ensues>

Looking at svn blame, this was a change made by Guido in r59477. In the
checkin, he points to issue 1597 where this was originally discussed.

So I suggest that the original patch be applied. I have not checked if
there are other cases in util.py where this should be cleaned up.

I also think it would be reasonable to change the try/finally's to
with's, since those are the very places that the 2.x code differs from
the 3.x code. But as I said, I don't feel too strongly about that.

I don't know why this problem doesn't show up in 2.x. I agree it would
be nice to understand why, but I don't have time to research it. Since
the new code (with try/finally) looks "more correct", if there's a
desire to keep them in sync then the try/finally fixes should be
back-ported to 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 16:54:58 2009
From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=)
Date: Thu, 17 Sep 2009 14:54:58 +0000
Subject: [issue6931] awful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>


New submission from Hei?ar Rafn Har?arson <heidar.rafn at hrolfsskali.net>:

Relatively small set of lines with differences in most lines can destroy
the performance of difflib.HtmlDiff.make_table and difflib.ndiff.
I am using it like this:
    ...
    htmldiffer = HtmlDiff()
    return htmldiffer.make_table(src_lines, dst_lines, 
        fromdesc="file1",
        todesc="file2",
        context=True)

I have written the src_lines and dst_lins to files and tried this with
the Tools/scripts/diff.py wrapper with same results when using the
switches -m or -n.
The performance is fine when using difflib.unified_diff or switch -u on
diff.py

Attached are files that show this clearly.
left200.txt,right200.txt - 200 lines of text - duration 11 seconds.
left500.txt,right500.txt - 500 lines of text - duration 2min 58 sec
left1000.txt,right1000.txt - 1000 lines of text - duration 29min 4sec

tested on Intel dualcore T2500 2GHz with 2 GB of memory, python 2.5.2 on
Ubuntu. Same problom on python 2.6 on Fedora-11
For reference, the kdiff3 utility performs beautifully on these files.

----------
components: Library (Lib)
files: python.difflib.bug.tgz
messages: 92768
nosy: heidar.rafn
severity: normal
status: open
title: awful performance in difflib: ndiff and HtmlDiff
type: performance
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14911/python.difflib.bug.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:01:54 2009
From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=)
Date: Thu, 17 Sep 2009 15:01:54 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1253199714.55.0.794650805771.issue6931@psf.upfronthosting.co.za>


Changes by Hei?ar Rafn Har?arson <heidar.rafn at hrolfsskali.net>:


----------
title: awful performance in difflib: ndiff and HtmlDiff -> dreadful performance in difflib: ndiff and HtmlDiff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:03:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 17 Sep 2009 15:03:14 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253156103.95.0.759308995146.issue6919@psf.upfronthosting.co.za>
Message-ID: <4AB24FA7.3090107@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If you do not *want* to change it, that is your prerogative, but it 
> *can* definitely work.

I don't believe it can work; Amaury has already given a number of
reasons. If you still believe otherwise, and want to see something
change, please try coming up with a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:25:02 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Sep 2009 15:25:02 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253201102.55.0.377120226712.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Indeed, the code that introduced this bug was in r68489, so it was
written after Guido went through the module and cleaned it up to use
try/finally. And since r68489 was a merge of r68487, the change was
originally made on the 2.x version (which doesn't use try/finally) to
the 3.x version (which does).

Which makes me think that we should go back and add try/finally to all
the popen calls in the 2.x version, so that it serves as a better
example when/if new popen calls are added. I'm willing to do that once
this issue is resolved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:36:35 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 17 Sep 2009 15:36:35 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1253197865.52.0.213706367987.issue6882@psf.upfronthosting.co.za>
Message-ID: <4AB2577E.3010403@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> The py3k version of the file already contains 3.x only code, and it's
> missing the comment at the top that it should be compatible. But it's
> not really a big deal to me.

Yes, I had deleted the comment since the 3.x code cannot be compatible with
2.x anyway (and I didn't remember that in my previous comment).

> So I suggest that the original patch be applied. I have not checked if
> there are other cases in util.py where this should be cleaned up.
> 
> I also think it would be reasonable to change the try/finally's to
> with's, since those are the very places that the 2.x code differs from
> the 3.x code. But as I said, I don't feel too strongly about that.

> I don't know why this problem doesn't show up in 2.x. I agree it would
> be nice to understand why, but I don't have time to research it. Since
> the new code (with try/finally) looks "more correct", if there's a
> desire to keep them in sync then the try/finally fixes should be
> back-ported to 2.x.

So I would suggest the following approach:  Add try/finally in py3k branch
where missing, backport the patch to 2.x, and then change the try/finally
into with blocks in py3k branch but do not backport this.

If you have the time, and if you have commit privs could you please go ahead?

Thanks, Thomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:37:24 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 17 Sep 2009 15:37:24 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253201844.97.0.621576633148.issue6882@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
assignee: theller -> eric.smith
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:37:30 2009
From: report at bugs.python.org (Joel Martin)
Date: Thu, 17 Sep 2009 15:37:30 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1253201850.24.0.990574988041.issue1731717@psf.upfronthosting.co.za>


Joel Martin <pythonbugs at martintribe.org> added the comment:

I can reproduce the problem (or at least get the same symptom) by doing
this (in 2.4.6, 2.5.4 and 2.6.2):

import subprocess, signal
signal.signal(signal.SIGCLD, signal.SIG_IGN)
subprocess.Popen(['echo','foo']).wait()

The echo command completes, but the subprocess command throws the "no
child" exception. It seems like the subprocess command should either:

- detect that SIGCLD is not set correctly and throw a more informative
exception before running the command.
- override SIGCLD during the running of the sub-command. Not sure what
the UNIX correctness implications of this are.
- or allow the child to zombie without throwing an exception. The fact
that the programmer has overridden SIGCLD sort of implies that reaping
of zombie children has been switched off.

I don't have good enough understanding of the underlying implementation
to know if this is a reproducer as requested or if this should be a new
bug. Please advise and I will file a new bug if requested.

This is a follow-up to trying to resolve this problem in the PEP 3143
python-daemon module. See this thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/9a853d0308c8e55a

----------
nosy: +kanaka
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:55:57 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 17 Sep 2009 15:55:57 +0000
Subject: [issue6932] Open shelves fail when Python exits
In-Reply-To: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za>
Message-ID: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

I'm reopening issue5483 by Zhigang Wang (zhigang) as a separate bug.

Shelves that are still open when Python terminates will try to sync. If
writeback=True, this pickles cached items.

In this example, serialization of Test() re-imports __main__, which is
already gc'd, and raises:
Exception cPickle.PicklingError: Can't pickle <class '__main__.Test'>:
it's not the same object as __main__.Test" in <bound method
Shelf.__del__ of {'a': <__main__.Test object at 0x...>}>

The error is ignored (due to Python already tearing down) but all cached
modifications are lost.
The promise "[t]he __del__() method of the Shelf class calls the close()
method, so the programmer generally need not do this explicitly" is not
true with writeback enabled.

I'm unsure if this error can be fixed (probably with atexit/weakref, but
that's more trouble than gain). I attached a patch to the docs simply
warning the user of this issue (+ documenting Shelf.close, + removing
above quote).

----------
assignee: georg.brandl
components: Documentation, Extension Modules, Library (Lib)
files: example.py
messages: 92773
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Open shelves fail when Python exits
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14912/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6932>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:56:43 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 17 Sep 2009 15:56:43 +0000
Subject: [issue6932] Open shelves fail when Python exits
In-Reply-To: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za>
Message-ID: <1253203003.27.0.248582230185.issue6932@psf.upfronthosting.co.za>


Changes by Robert Lehmann <lehmannro at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14913/shelve-warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6932>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:58:27 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 17 Sep 2009 15:58:27 +0000
Subject: [issue5483] [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache
	even when writeback=True
In-Reply-To: <1236949925.76.0.785103969967.issue5483@psf.upfronthosting.co.za>
Message-ID: <1253203107.4.0.770201994158.issue5483@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I addressed the other bug you were experiencing in issue6932.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5483>
_______________________________________

From report at bugs.python.org  Thu Sep 17 17:59:11 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Thu, 17 Sep 2009 15:59:11 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1253203151.2.0.415905466923.issue6729@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

I can give it a shot if you give me a rough idea where I have to make
the appropriate changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Thu Sep 17 18:16:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 16:16:20 +0000
Subject: [issue6932] Open shelves fail when Python exits
In-Reply-To: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za>
Message-ID: <1253204180.83.0.997252445126.issue6932@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed docs (a bit differently) in r74876.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6932>
_______________________________________

From report at bugs.python.org  Thu Sep 17 18:17:53 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 17 Sep 2009 16:17:53 +0000
Subject: [issue6883] OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <1253182712.81.0.920592301599.issue6883@psf.upfronthosting.co.za>
Message-ID: <19122.24877.11341.349082@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Georg> The (en|dis)able_interspersed_args accessors are already
    Georg> documented, so I see no reason to document the attribute as
    Georg> well...

But it is documented in the class's docstring and there are no docstrings
for the methods.  It's not at all clear which is the "best" way to change
that particular behavior.

Skip

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6883>
_______________________________________

From report at bugs.python.org  Thu Sep 17 18:21:59 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 16:21:59 +0000
Subject: [issue6883] OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
Message-ID: <1253204519.49.0.931062965125.issue6883@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The methods do have docstrings (trunk rev, line 1283 and 1291).

And usually, when there are accessors for a property, they are the
preferred way to change it.

Anyway, I don't see a reason to do something here, so please propose a
patch if you still think the docs inadequate.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6883>
_______________________________________

From report at bugs.python.org  Thu Sep 17 18:57:03 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 17 Sep 2009 16:57:03 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253206623.4.0.888415134253.issue6929@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, then only rawIoBase's documentation is wrong... and I'll have
to modify my work-in-progress library to mimic FileIo more accurately.
Thansk for teh info B-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:00:50 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 17 Sep 2009 17:00:50 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253206850.84.0.692291045398.issue6929@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I forgot to note - yep I was actually improperly looking at the python
2.6 documentation, which is erroneous ocncerning the io module.
But the py3k doc seems to summarize it allright B-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:01:01 2009
From: report at bugs.python.org (Moray Grieve)
Date: Thu, 17 Sep 2009 17:01:01 +0000
Subject: [issue6933] Threading issue with Tkinter Frame.insert
In-Reply-To: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za>
Message-ID: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za>


New submission from Moray Grieve <mbg at progress.com>:

The attached file has an example where a Tk GUI is launched as a
seperate thread - this all works fine in Python 2.5, but in Python 2.6
the thread hangs. 

The issue seems to be in the line;

self.messageBoxDetails.insert(INSERT, "Hello world")

Comment this line out, or use an empty string rather than "Hello World",
and the example works in both Python 2.5 and Python 2.6. I have not been
able to seen any related issues to this and wonder if this is a bug in
the 2.6 Tkinter module.

----------
components: Tkinter
files: example.py
messages: 92781
nosy: moraygrieve
severity: normal
status: open
title: Threading issue with Tkinter Frame.insert
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14914/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6933>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:04:24 2009
From: report at bugs.python.org (Moray Grieve)
Date: Thu, 17 Sep 2009 17:04:24 +0000
Subject: [issue6933] Threading issue with Tkinter Frame.insert
In-Reply-To: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za>
Message-ID: <1253207064.83.0.084237452153.issue6933@psf.upfronthosting.co.za>


Moray Grieve <mbg at progress.com> added the comment:

I should say this is running on Windows XP

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6933>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:20:23 2009
From: report at bugs.python.org (Santhosh Thottingal)
Date: Thu, 17 Sep 2009 17:20:23 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1253208023.28.0.363368921547.issue6895@psf.upfronthosting.co.za>


Santhosh Thottingal <santhosh.thottingal at gmail.com> added the comment:

Attached the testcases as a patch to Lib/test/test_locale.py

----------
Added file: http://bugs.python.org/file14915/test_locale.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6895>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:26:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Sep 2009 17:26:30 +0000
Subject: [issue6929] Confusion between "write" method of rowiobase and
	rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253208390.28.0.395137876227.issue6929@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Checked in a bunch of corrections and precisions in r74879, and r74880.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:44:49 2009
From: report at bugs.python.org (=?utf-8?q?Patrick_N=C3=A4f?=)
Date: Thu, 17 Sep 2009 17:44:49 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1253209489.54.0.992452423399.issue6860@psf.upfronthosting.co.za>


Patrick N?f <herzbube at herzbube.ch> added the comment:

>To be able to do this fix, I also need to change the way commands are
>registered in Distutils.

Hm, I thought commands were registered in the setup() function with the
cmdclass dict. Like this:

setup(
      # "test" is the name that should be used for display
      cmdclass = { "test" : TestClass },
     )

And the dict key can then be used as the name to display. At least
"--help-commands" does it this way.


Please note that I don't want to criticize: I'm just a dumb user who
hasn't spent 5 seconds investigating how distutils works. I just
thought, maybe you have overlooked something and this could save you
some time...

Anyway, thanks for taking this on.

Patrick

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:46:16 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Thu, 17 Sep 2009 17:46:16 +0000
Subject: [issue6934] postflight.framework script (from the Mac OS X .dmg
	installer) fails (patch given).
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>


New submission from Svetoslav Agafonkin <svetlyo at gmail.com>:

postflight.framework fails during installation:

. . .
Sep 17 17:36:53 mcfro Installer[1613]: run postflight script for Python 
Framework
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 9: 
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such 
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: 
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 14: 
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such 
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 19: 
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such 
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: 
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python 
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 24: 
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such 
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: 
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: chown: admin: 
Invalid argument
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: 

The first problem is that in 
/Library/Frameworks/Python.framework/Versions/3.1/bin there is no 
executable 'python' anymore - there is 'python3.1', etc.

Also chown at the end should set the group to 'admin', not the owner.

I've attached a patch that fixes these issues. (the problem with chown 
is also present in the installer for 2.6.x ).

----------
assignee: ronaldoussoren
components: Installation, Macintosh
files: postflight.framework.patch
keywords: patch
messages: 92786
nosy: ronaldoussoren, slavi
severity: normal
status: open
title: postflight.framework script (from the Mac OS X .dmg installer) fails (patch given).
type: compile error
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14916/postflight.framework.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:49:49 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Thu, 17 Sep 2009 17:49:49 +0000
Subject: [issue6934] postflight.framework script (from the Mac OS X .dmg
	installer) fails (patch given).
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253209789.95.0.982075409236.issue6934@psf.upfronthosting.co.za>


Changes by Svetoslav Agafonkin <svetlyo at gmail.com>:


Removed file: http://bugs.python.org/file14916/postflight.framework.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:50:03 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Thu, 17 Sep 2009 17:50:03 +0000
Subject: [issue6934] postflight.framework script (from the Mac OS X .dmg
	installer) fails (patch given).
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253209803.48.0.141398454621.issue6934@psf.upfronthosting.co.za>


Changes by Svetoslav Agafonkin <svetlyo at gmail.com>:


Added file: http://bugs.python.org/file14917/postflight.framework.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Thu Sep 17 19:59:24 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Sep 2009 17:59:24 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253210364.39.0.632360221811.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Yes, I'll take care of this.

I can't think of any way to add a test that the zombie process doesn't
exist, but if anyone has an idea I'd like to hear about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Sep 17 20:03:15 2009
From: report at bugs.python.org (Travis H.)
Date: Thu, 17 Sep 2009 18:03:15 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253210595.98.0.37744753717.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

Simplified if/else chaining

Uploading here before testing on new machine (m4 was too old on previous
machine)

----------
Added file: http://bugs.python.org/file14918/foo.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Thu Sep 17 20:20:16 2009
From: report at bugs.python.org (Jeff Bradberry)
Date: Thu, 17 Sep 2009 18:20:16 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253211616.27.0.851754179319.issue6300@psf.upfronthosting.co.za>


Jeff Bradberry <jeff.bradberry at gmail.com> added the comment:

Before:

~/python2.7$ ./python -mtimeit "u'Andr\202 x'.encode('ascii', 'replace')"
1000000 loops, best of 3: 1.8 usec per loop

After:

~/python2.7-patched$ ./python -mtimeit "u'Andr\202 x'.encode('ascii',
'replace')"
1000000 loops, best of 3: 1.73 usec per loop


The difference in performance seems to be trivial, perhaps favoring the
patched version slightly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:01:58 2009
From: report at bugs.python.org (=?utf-8?q?Mat=C3=ADas_Ribecky?=)
Date: Thu, 17 Sep 2009 19:01:58 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1253214118.79.0.479875102901.issue5207@psf.upfronthosting.co.za>


Changes by Mat?as Ribecky <mail at mribecky.com.ar>:


----------
nosy: +mribecky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:05:16 2009
From: report at bugs.python.org (Travis H.)
Date: Thu, 17 Sep 2009 19:05:16 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253214316.93.0.40087209434.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

I applied the same patch to Python 2.6.2 and believe that I got the
tab/space situation worked out so that it's consistent with the rest of
posixmodule.c

I also executed autoconf to convert configure.in to configure, and
judging by the config.log, it is testing for and finding setresuid and
friends.  It is also defining HAVE_SETRESUID to 1 as expected.  However,
when I execute this python and import os (or posix), it says that module
doesn't have the setresuid attribute.

I ran "strings" on libpython2.6a and found that it has the strings
"setuid" and "setreuid" as expected, but not my "setresuid".

Does anyone have any idea why this might be?  I'm trying hard to get
this into python but I'm not an expert on how the build works.

----------
keywords: +patch
Added file: http://bugs.python.org/file14919/setresuid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:17:04 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Thu, 17 Sep 2009 19:17:04 +0000
Subject: [issue6934] {PATCH} postflight.framework script (from the Mac OS X
	.dmg installer) fails.
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253215024.8.0.648274019934.issue6934@psf.upfronthosting.co.za>


Changes by Svetoslav Agafonkin <svetlyo at gmail.com>:


----------
title: postflight.framework script (from the Mac OS X .dmg installer) fails (patch given). -> {PATCH} postflight.framework script (from the Mac OS X .dmg installer) fails.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:17:43 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Thu, 17 Sep 2009 19:17:43 +0000
Subject: [issue6934] [PATCH] postflight.framework script (from the Mac OS X
	.dmg installer) fails.
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253215063.94.0.701630264042.issue6934@psf.upfronthosting.co.za>


Changes by Svetoslav Agafonkin <svetlyo at gmail.com>:


----------
title: {PATCH} postflight.framework script (from the Mac OS X .dmg installer) fails. -> [PATCH] postflight.framework script (from the Mac OS X .dmg installer) fails.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:43:42 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 17 Sep 2009 19:43:42 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253216622.04.0.146046003744.issue6300@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Perfect. Thanks for checking.

Benjamin, could you please check this in ? Thanks.

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:49:03 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 17 Sep 2009 19:49:03 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253216943.43.0.7383730596.issue5042@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Thu Sep 17 21:53:39 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 17 Sep 2009 19:53:39 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253217219.26.0.428566741169.issue5042@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The problem is the implementation of the current __init__ method, in
Modules/_ctypes/_ctypes.c, line 4024.  Rewritten in Python, and slightly
simplified it looks like this:

    def __init__(self, *args, **kw):
        """The current BUGGY __init__ method"""
        names = [f[0] for f in self._fields_]
        for n, v in zip(names, args):
            setattr(self, n, v)
        for n, v in kw.iteritems():
            setattr(self, n, v)

It assigns positional parameters to the names found in the _fields_ list
of the subclass, but it should look up all the _fields_ definitions in
all the superclasses, too.  Working pseudo Python code:

    def __init__(self, *args, **kw):
        """This is how the Structure's __init__method SHOULD be"""
        if args:
            names = []
            for tp in self.__class__.mro()[2::-1]:
                for n, _ in tp._fields_:
                    names.append(n)
            for n, v in zip(names, args):
                setattr(self, n, v)
        for n, v in kw.iteritems():
            setattr(self, n, v)

Now, I don't really want to write the above code in C ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Thu Sep 17 22:00:14 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Sep 2009 20:00:14 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253217614.69.0.294678868433.issue5042@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Heh.  Me neither.

Is it possible to use something like Cython to generate the C code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Thu Sep 17 22:09:07 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Sep 2009 20:09:07 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253218147.13.0.782038011817.issue5042@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That was easier than I thought. The generated code is _ugly_ but it did
seem to be able to generate it.

I created init.pyx

{{{
class X(object):
	def __init__(self, *args, **kw):
		"""This is how the Structure's __init__method SHOULD be"""
		if args:
			names = []
			for tp in self.__class__.mro()[2::-1]:
				for n, _ in tp._fields_:
					names.append(n)
			for n, v in zip(names, args):
				setattr(self, n, v)
		for n, v in kw.iteritems():
			setattr(self, n, v)
}}}

Then, ran cython init.pyx and got the attached file.

Is that any help?

----------
Added file: http://bugs.python.org/file14920/init.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Thu Sep 17 22:48:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Sep 2009 20:48:49 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253220529.03.0.669549150289.issue6300@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I still have a few things I would like changed:

- Instead of listing which methods take keyword arguments at the top of
the section, I would prefer that each used the "versionchanged: 2.7"
directive and indicated the added ability to use keyword arguments.
- Your tests only cover str.decode and unicode.encode, not vice-versa.
- In your tests, there should be a space between the comma in the
arguments and the next argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Sep 17 23:19:33 2009
From: report at bugs.python.org (nh2)
Date: Thu, 17 Sep 2009 21:19:33 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1253222373.76.0.150069566962.issue2504@psf.upfronthosting.co.za>


nh2 <nh2 at deditus.de> added the comment:

Me too. This makes developing applications with good localizations in
Python really difficult.

----------
nosy: +nh2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu Sep 17 23:27:44 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Sep 2009 21:27:44 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1253222864.65.0.78503747654.issue6895@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/issue6895>
_______________________________________

From report at bugs.python.org  Thu Sep 17 23:37:59 2009
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 17 Sep 2009 21:37:59 +0000
Subject: [issue4033] python search path - .pth recursion
In-Reply-To: <1223068509.57.0.8948521791.issue4033@psf.upfronthosting.co.za>
Message-ID: <1253223479.78.0.892689730311.issue4033@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Looks like 1431 was closed by removing a line from the documentation, so
it's not surprising that it's not clear.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4033>
_______________________________________

From report at bugs.python.org  Fri Sep 18 01:30:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 17 Sep 2009 23:30:26 +0000
Subject: [issue6935] Version updates needed in tutorial
In-Reply-To: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za>
Message-ID: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Footnote 1 in section 2.1 of the Tutorial and the example of invoking
Python in the middle of the page need their version number upped to 3.2
in both the invocation and the greeting.

The same page in the 3.1 documentation should have the 'a' removed from
the version number in the greeting.

----------
assignee: georg.brandl
components: Documentation
messages: 92798
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Version updates needed in tutorial
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6935>
_______________________________________

From report at bugs.python.org  Fri Sep 18 01:38:03 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 17 Sep 2009 23:38:03 +0000
Subject: [issue6936] Import needed to quit Python?
In-Reply-To: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za>
Message-ID: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Section 2.1 of the tutorial describes using import sys; sys.exit() if ^D
or ^Z doesn't work. However, both quit() and exit() work, as documented
in the "Built-in Constants" section of the Library documentation. Is
there something about them that should be hidden from the ordinary user
that they aren't used in place of the import sys; sys.exit()
combination? Seems easier to just say use "quit() or exit()", especially
for beginners following the tutorial who won't know what import or sys
are, or even the dot notation.

----------
assignee: georg.brandl
components: Documentation
messages: 92799
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Import needed to quit Python?
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6936>
_______________________________________

From report at bugs.python.org  Fri Sep 18 02:24:35 2009
From: report at bugs.python.org (Jim Baker)
Date: Fri, 18 Sep 2009 00:24:35 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1253233475.41.0.864062449781.issue4111@psf.upfronthosting.co.za>


Changes by Jim Baker <jbaker at zyasoft.com>:


----------
nosy: +jbaker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Sep 18 06:35:37 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Sep 2009 04:35:37 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253248537.33.0.256476769632.issue6925@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Except for the variable name and 3.1 print(), that is exactly what I
tested before posting:
>>> 
{}

Was 2.x different?

Anyway, from Wikipedia: "In computer programming, a free variable is a
variable referred to in a function that is not a local variable or an
argument of that function." (from page called 'Free variables in Lisp")
Globals qualify under that definition. It goes on to say "An upvalue is
a free variable that has been bound (closed over) with a closure." which
is what Python calls nonlocal or cell var.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Fri Sep 18 07:10:44 2009
From: report at bugs.python.org (aaditya sood)
Date: Fri, 18 Sep 2009 05:10:44 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>


New submission from aaditya sood <aaditya at sood.net.in>:

On a Snow Leopard system, doing this core dumps:

import multiprocessing
lck1=multiprocessing.Lock()

with lck1:
    print "foo"

The stack trace:

Process:         Python [23100]
Path:           
/System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  zsh [23055]

Date/Time:       2009-09-18 10:39:39.611 +0530
OS Version:      Mac OS X 10.6.1 (10B504)
Report Version:  6

Interval Since Last Report:          83665 sec
Crashes Since Last Report:           60
Per-App Crashes Since Last Report:   55
Anonymous UUID:                      38A426BB-52F7-4282-9FA8-A04AB8896489

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000043000000ee
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.python.python             	0x0000000100096763
_PyArg_ParseTupleAndKeywords_SizeT + 113
1   _multiprocessing.so           	0x00000001001fa8c8 sem_timedwait_save
+ 456
2   org.python.python             	0x00000001000891df PyEval_EvalFrameEx
+ 15001
3   org.python.python             	0x000000010008accf PyEval_EvalCodeEx
+ 1803
4   org.python.python             	0x000000010008ad62 PyEval_EvalCode + 54
5   org.python.python             	0x00000001000a265a Py_CompileString + 78
6   org.python.python             	0x00000001000a44dd
PyRun_InteractiveOneFlags + 503
7   org.python.python             	0x00000001000a4615
PyRun_InteractiveLoopFlags + 206
8   org.python.python             	0x00000001000a4685
PyRun_AnyFileExFlags + 76
9   org.python.python             	0x00000001000b0286 Py_Main + 2718
10  org.python.python.app         	0x0000000100000e6c start + 52

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000004300000043  rbx: 0x0000000100200150  rcx:
0x00000001001fc7f0  rdx: 0x00000001001fb632
  rdi: 0x00000001001af050  rsi: 0x000000010003af24  rbp:
0x00007fff5fbfeff0  rsp: 0x00007fff5fbfef20
   r8: 0x0000000100096748   r9: 0x00007fff5fbff030  r10:
0x0000000000000000  r11: 0x00000001001fa86f
  r12: 0x00000000ffffffff  r13: 0x00000001004a4570  r14:
0x0000000100123100  r15: 0x00000001001af050
  rip: 0x0000000100096763  rfl: 0x0000000000010206  cr2: 0x00000043000000ee

Binary Images:
       0x100000000 -        0x100000ff7  org.python.python.app 2.6 (2.6)
<BDEA119D-4E2F-D97F-07BA-713A6E5A39B6>
/System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
       0x100004000 -        0x100114ff7  org.python.python 2.6.1 (2.6.1)
<01EBD0D4-F181-045F-C7A8-B7B3C5D4204F>
/System/Library/Frameworks/Python.framework/Versions/2.6/Python
       0x1001f0000 -        0x1001f2ff7  readline.so ??? (???)
<A8236667-A9DD-30A5-6DE8-201C6EF317E6>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/readline.so
       0x1001f8000 -        0x1001fbfff  _multiprocessing.so ??? (???)
<03672D74-6FAC-DE76-6DE6-604A8C0F2D50>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_multiprocessing.so
       0x1004b0000 -        0x1004ccff7  libedit.2.dylib ??? (???)
<F9D005F8-74B8-CC05-2697-24C49E0CC1EF> /usr/lib/libedit.2.dylib
       0x1004db000 -        0x1004e0fff  itertools.so ??? (???)
<06555874-952C-C770-64BF-6BC7A2455E10>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so
       0x1004e8000 -        0x1004f4fff  cPickle.so ??? (???)
<98485D07-D504-74EB-B3A1-4EBB2474BFE6>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cPickle.so
       0x1004fa000 -        0x1004fbfff  cStringIO.so ??? (???)
<7600C3A8-3C81-2A81-0853-B09107768C8C>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cStringIO.so
       0x100540000 -        0x100541ff7  _functools.so ??? (???)
<1CE29F88-7B8C-77CC-5E87-555BA210EA8F>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_functools.so
       0x100545000 -        0x100546ff7  time.so ??? (???)
<5F01F2A9-8557-5DF1-F006-44E02E0469CE>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/time.so
       0x10054d000 -        0x100550fff  _collections.so ??? (???)
<1F62A5C3-6E6C-D0BC-7AA6-DA2820B5F157>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_collections.so
       0x100556000 -        0x100559fff  operator.so ??? (???)
<68C1CC88-5F73-E029-5C19-685BBADACFA6>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/operator.so
       0x10055f000 -        0x10055ffff  _weakref.so ??? (???)
<89F1302D-1CFA-7B9B-4425-70DA55215DAE>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_weakref.so
       0x1005a3000 -        0x1005a7ff7  _struct.so ??? (???)
<33156F5C-52ED-7167-533F-15D6CF031150>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_struct.so
       0x1005ad000 -        0x1005affe7  binascii.so ??? (???)
<5CFE3DC5-850B-B79D-8310-0BA97540841A>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???)
<B633F790-4DDB-53CD-7ACF-2A3682BCEA9F> /usr/lib/dyld
    0x7fff80bc1000 -     0x7fff80bc5ff7  libmathCommon.A.dylib ??? (???)
<95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fff829f4000 -     0x7fff82bb2ff7  libSystem.B.dylib ??? (???)
<66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib
    0x7fff85ebc000 -     0x7fff85efbfef  libncurses.5.4.dylib ??? (???)
<E0A07C12-D912-DF26-9E38-C50484D96EB0> /usr/lib/libncurses.5.4.dylib
    0x7fff85f81000 -     0x7fff85f92fef  libz.1.dylib ??? (???)
<3A7A4C48-A4C8-A78A-8B87-C0DDF6601AC8> /usr/lib/libz.1.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???)
<66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib

Model: MacBookPro2,2, BootROM MBP22.00A5.B07, 2 processors, Intel Core 2
Duo, 2.16 GHz, 2 GB, SMC 1.12f5
Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87),
Atheros 5416: 2.0.19.4
Bluetooth: Version 2.2.1f7, 2 service, 1 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS541612J9SA00, 111.79 GB
Parallel ATA Device: HL-DT-ST DVDRW GWA4080MA
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8501, 0xfd400000
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8240, 0x5d200000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.),
0x021a, 0x1d200000
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8205,
0x7d100000

----------
components: Extension Modules
messages: 92801
nosy: aaditya
severity: normal
status: open
title: multiprocessing lock on OS X Snow Leopard dumps core
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 07:12:39 2009
From: report at bugs.python.org (aaditya sood)
Date: Fri, 18 Sep 2009 05:12:39 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253250759.52.0.944688965024.issue6937@psf.upfronthosting.co.za>


aaditya sood <aaditya at sood.net.in> added the comment:

Additional Info: Snow Leopard is shipping with Python 2.6.1 64 bit build.

----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 07:39:56 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Sep 2009 05:39:56 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253252396.92.0.295170405247.issue6937@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Reproducible here. Fails with Apple 2.6.1 in 64-bit mode but *not* in 
32-bit mode.  Also does not fail on 10.6 with recent 64-bit 4-way trunk  
built on 10.5.

$ arch -i386 /usr/bin/python2.6
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> lck1=multiprocessing.Lock()
>>> with lck1:
...   print "foo"
... 
foo
>>> ^D
$ arch -x86_64 /usr/bin/python2.6
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> lck1=multiprocessing.Lock()
>>> with lck1:
...   print "foo"
... 
Segmentation fault

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +nad, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 08:01:03 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 18 Sep 2009 06:01:03 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <20090918060053.GA6946@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

On Fri, Sep 18, 2009 at 04:35:37AM +0000, Terry J. Reedy wrote:
> Was 2.x different?

Even in 2.x it returns 
{}

And I thought that was expected. Even I am confused by the free
variable explaination as you pointed out. Perhaps, Georg could explain
better?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Fri Sep 18 08:02:53 2009
From: report at bugs.python.org (Henri Hein)
Date: Fri, 18 Sep 2009 06:02:53 +0000
Subject: [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253253773.68.0.768326129102.issue6919@psf.upfronthosting.co.za>


Henri Hein <henri at granitetower.net> added the comment:

Right, I was thinking about rebuilding Python26.dll.  If we do go down 
that path, I will report the results.

Thanks for the feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________

From report at bugs.python.org  Fri Sep 18 08:03:43 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Sep 2009 06:03:43 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253253823.28.0.133139788007.issue6937@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Jesse: is this something you can look into? 

This is a crash of multiprocessing on MacOSX 10.6 with a 64-bit build of 
python.

----------
assignee: ronaldoussoren -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 08:06:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Sep 2009 06:06:16 +0000
Subject: [issue6934] [PATCH] postflight.framework script (from the Mac OS X
	.dmg installer) fails.
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253253976.83.0.658336015493.issue6934@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thanks. I'll fix this over the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Fri Sep 18 08:42:19 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 18 Sep 2009 06:42:19 +0000
Subject: [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1253256139.35.0.1551257646.issue6767@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I think it is okay to close this, with Martin's Howto.

----------
nosy: +orsenthil
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Fri Sep 18 09:18:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 07:18:17 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253258297.44.0.347234509598.issue6925@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm sorry, I messed up the test.  When "x" is not used in g(), it's of
course *not* a free variable in g.  This is the correct test:

def f():
  x = 1
  def g():
    print x
    print locals()
  g()
f()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Fri Sep 18 09:19:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 07:19:40 +0000
Subject: [issue6936] Import needed to quit Python?
In-Reply-To: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za>
Message-ID: <1253258380.83.0.401419537984.issue6936@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

They are meant for interactive use only.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6936>
_______________________________________

From report at bugs.python.org  Fri Sep 18 09:22:59 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 07:22:59 +0000
Subject: [issue6936] Import needed to quit Python?
In-Reply-To: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za>
Message-ID: <1253258579.9.0.637989904321.issue6936@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And fixed now (I used ``quit()``) in r74896.

----------
resolution: works for me -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6936>
_______________________________________

From report at bugs.python.org  Fri Sep 18 09:29:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 07:29:10 +0000
Subject: [issue6935] Version updates needed in tutorial
In-Reply-To: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za>
Message-ID: <1253258950.46.0.182567035614.issue6935@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74897, r74898 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6935>
_______________________________________

From report at bugs.python.org  Fri Sep 18 09:44:56 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Sep 2009 07:44:56 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253259896.03.0.138520746289.issue6508@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Your patch looks good (except that in getresuid, you seem to be missing 
return). I have no clue why it doesn't work; I'll see whether I can try it 
out on Linux within the next few weeks.

The one puzzling detail is that you don't include a patch to 
pyconfig.h.in: did you run autoheader?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Fri Sep 18 09:48:59 2009
From: report at bugs.python.org (Tim Golden)
Date: Fri, 18 Sep 2009 07:48:59 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <4AB33BF8.1020902@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Don't know what exact release OS X ships with, but it
looks like you're being bitten by this:

http://bugs.python.org/issue5261

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 10:24:34 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Sep 2009 08:24:34 +0000
Subject: [issue5652] OS X Installer: remove references to Mac/Tools which no
	longer exists
In-Reply-To: <1238603386.16.0.0582109660822.issue5652@psf.upfronthosting.co.za>
Message-ID: <1253262274.28.0.629630068323.issue5652@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See also Issue6934 for Python3 fix.

----------
assignee:  -> ronaldoussoren
components: +Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5652>
_______________________________________

From report at bugs.python.org  Fri Sep 18 10:25:11 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Sep 2009 08:25:11 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253262311.05.0.525311824438.issue5042@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

> Is that any help?
Not really ;-).

Here is a patch I just wrote - it must still be checked for correctness,
and tests for it must be added.  I hope the comment in the code explains
how it works.  ctypes-structinit.patch

----------
keywords: +patch
Added file: http://bugs.python.org/file14921/ctypes-structinit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Fri Sep 18 10:26:36 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Sep 2009 08:26:36 +0000
Subject: [issue6934] [PATCH] postflight.framework script (from the Mac OS X
	.dmg installer) fails.
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253262396.56.0.898116915381.issue6934@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Issue5652 suggests removing the Mac/Tools references here and in trunk.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Fri Sep 18 11:06:51 2009
From: report at bugs.python.org (Zhang Cong)
Date: Fri, 18 Sep 2009 09:06:51 +0000
Subject: [issue6938] Incorrect multiprocessing log string in managers.py
	(python 2.6.2)
In-Reply-To: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za>
Message-ID: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za>


New submission from Zhang Cong <ftofficer at ftofficer.com>:

There is an issue in multiprocessing library.
Lib/multiprocessing/managers.py:413:

util.debug('disposing of obj with id %d', ident)

It is '%d' here, but 'ident' is a string.

This always cause an TypeError from logging module once enable logging
on multiprocessing.

Patch is attached to fix the issue.

----------
components: Library (Lib)
files: managers-log.patch
keywords: patch
messages: 92818
nosy: ftofficer
severity: normal
status: open
title: Incorrect multiprocessing log string in managers.py (python 2.6.2)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14922/managers-log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6938>
_______________________________________

From report at bugs.python.org  Fri Sep 18 11:15:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 09:15:00 +0000
Subject: [issue6905] inspect.getargspec(print) fails
In-Reply-To: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>
Message-ID: <1253265300.01.0.897170142706.issue6905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, that is reasonable. I changed this and several other same-style
errors in r74901.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6905>
_______________________________________

From report at bugs.python.org  Fri Sep 18 11:18:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 09:18:45 +0000
Subject: [issue6938] Incorrect multiprocessing log string in managers.py
	(python 2.6.2)
In-Reply-To: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za>
Message-ID: <1253265525.8.0.615457285282.issue6938@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74903; I used %r as the format code to match the formatting in
create().

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6938>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:04:05 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 18 Sep 2009 13:04:05 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253279045.82.0.98959309454.issue6937@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

AFAIK: Tim is correct. Unfortunately, this has already been fixed - as 
much as it kills me, there's not much I can do to fix this for Snow 
Leopard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:21:53 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 18 Sep 2009 13:21:53 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

I'm having trouble around the behaviour of the io module's truncate
methods, in py3k. If I remember well, under unix and older versions of
Python (with other file types), truncate never move the fiel pointer
(and had to fake that behaviour under windows as well, by
saving/restoring the file pointer).

However, I see nothing in the documentation of the io module about that,
and studying the _fileio.c code, it seems that now the file pointer is
(under all OS) moved to the truncation point, and left there.

Maybe it requires discusions on the mailing list, but personally I think
that the common unix behaviour (letting the file pointer untouched)
would be better for everyone, and that the doc should claim it.

Also, additional notes about the behaviour of that truncation (reminding
people that on some OS, the padding is zero-filled, on others it's
not...) would be great.

Current doc of io in py3k :
http://docs.python.org/py3k/library/io.html#io.IOBase.truncate
truncate(size=None)
    Truncate the file to at most size bytes. size defaults to the
current file position, as returned by tell().

Cheers
Pascal

----------
components: IO
messages: 92822
nosy: pakal
severity: normal
status: open
title: shadows around the io truncate() semantics
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/issue6939>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:41:44 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Sep 2009 13:41:44 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1253281304.9.0.832610560348.issue4111@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:48:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Sep 2009 13:48:58 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253281738.87.0.466581146979.issue6937@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Jesse: Apple can fix their own copy of python (which is 2.6.1), I was more 
worried about the upcoming 2.6.3 release.

I'll file a bug with Apple and poke their Python maintainer once 2.6.3  is 
released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:49:15 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Sep 2009 13:49:15 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253281755.46.0.520103822874.issue6937@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee: jnoller -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:58:09 2009
From: report at bugs.python.org (Rajarshi)
Date: Fri, 18 Sep 2009 13:58:09 +0000
Subject: [issue6940] cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2
In-Reply-To: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za>
Message-ID: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za>


New submission from Rajarshi <rajarshi.guha at gmail.com>:

OS 10.5.7, Python 2.6.2 sources. 

When I execute:

/configure --enable-framework=/Library/Frameworks \
--enable-universalsdk=/ \
MACOSX_DEPLOYMENT_TARGET=10.5 \
--with-universal-archs=all \
--with-readline-dir=/usr/local

configure fails with the error
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)

However, if I replace all with 64-bit, it works fine. I note that this
issue was reported for OS X 10.4 and fixed. But this still happens

gcc information is

Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5490)

----------
components: Build
messages: 92824
nosy: rajarshi
severity: normal
status: open
title: cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6940>
_______________________________________

From report at bugs.python.org  Fri Sep 18 15:59:09 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 18 Sep 2009 13:59:09 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253282349.03.0.76710373758.issue6937@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ronald, could you email me the incantation for a full-on 64 bit build, 
I'll double check this on 26-maint. I just forget the magic build flags 
all the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Fri Sep 18 16:06:21 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Sep 2009 14:06:21 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1253282781.92.0.735928375491.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I checked in a slightly modified version of Marcin's patch in py3k
(r74907) and release31-maint (r74909). I modified the patch to keep the
same style as the rest of the module.

I'll now work on back-porting all of the try/finally code to trunk. That
includes this change as well as the ones made in prior checkins (like
r59477). I'll probably not back-port that to 2.6, since it doesn't
actually fix any bugs, it's just an effort to keep the code in sync and
be "more correct".

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Fri Sep 18 16:58:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Sep 2009 14:58:46 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1253285926.52.0.168474830989.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't tell you why it was decided to behave like this. Perhaps it was
felt that, since FileIO is low-level (lower than the file object in
2.x), it shouldn't have to remember and restore the old file position.
That argument wouldn't apply to BufferedWriter, though.

I'm afraid I don't know anything about the padding differences myself.
If you give us more precisions on the subject, we will be able to
include them in the documentation.

----------
assignee:  -> pitrou
components: +Documentation
nosy: +pitrou
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Sep 18 17:04:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Sep 2009 15:04:59 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1253286299.47.0.906098685944.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The now unused arbitrary base conversion was removed in r74910 (py3k).  
I'm deliberately going to leave it in in the trunk, just in case there's 
third party code that's using _PyLong_Format.  (There shouldn't be, given 
the '_Py' prefix, but you never know.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Fri Sep 18 18:21:50 2009
From: report at bugs.python.org (Tom)
Date: Fri, 18 Sep 2009 16:21:50 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1253290910.24.0.0238469658538.issue3890@psf.upfronthosting.co.za>


Tom <tmm at fastmail.fm> added the comment:

I have just encountered this bug on Python 2.6.2 on Windows.  I hope the
fix makes it into 2.6.3.  Thanks for the patch.

----------
nosy: +qwavel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Fri Sep 18 18:31:55 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 18 Sep 2009 16:31:55 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1253291515.1.0.187212658942.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

This patch fixes a number of typos in the original and, to my knowledge,
is now complete.

I have tested this manually and confirmed that it works.  I would start
as root, setresuid/gid to some non-root uid/gids, getresuid/gid to test
those functions, and follow it up with os.system("id") to check using an
outside utility.

----------
Added file: http://bugs.python.org/file14923/res.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Fri Sep 18 18:33:26 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 18 Sep 2009 16:33:26 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1253259896.03.0.138520746289.issue6508@psf.upfronthosting.co.za>
Message-ID: <20090918163318.GL1720@subspacefield.org>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

On Fri, Sep 18, 2009 at 07:44:56AM +0000, Martin v. L??wis wrote:
> 
> Your patch looks good (except that in getresuid, you seem to be missing 
> return). I have no clue why it doesn't work; I'll see whether I can try it 
> out on Linux within the next few weeks.

I am testing it out now on a more up-to-date machine.

> The one puzzling detail is that you don't include a patch to 
> pyconfig.h.in: did you run autoheader?

No, I did not - it has been a long time since I was familiar with
autotools - and that was why there was no access to these functions
when I compiled before.

I've now got a complete, tested patch up on bugs.python.org
-- 
Obama Nation | My emails do not have attachments; it's a digital signature
that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Fri Sep 18 18:34:07 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 18 Sep 2009 16:34:07 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1253291647.54.0.0560865065854.issue3890@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

The patch looks good as it just removes the while loop.
This is a high priority issue and should be fixed as soon as possible, 
imho, as it makes impossible to use ssl module with non blocking sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Fri Sep 18 19:15:52 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 18 Sep 2009 17:15:52 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1253294152.59.0.327768912799.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Well, I guess it deserve discussion on the pydev mailing lits, that's
imo a rather important point, to be documented precisely.

Concerning the padding, I guess the semantic doesn't change between the
io module and the old file type, i.e :

file.truncate([size])?
    Truncate the file?s size. If the optional size argument is present,
the file is truncated to (at most) that size. The size defaults to the
current position. The current file position is not changed. Note that if
a specified size exceeds the file?s current size, the result is
platform-dependent: possibilities include that the file may remain
unchanged, increase to the specified size as if zero-filled, or increase
to the specified size with undefined new content. Availability: Windows,
many Unix variants.

Having platform-dependent semantics for a so important type is anyway
dangerous, I feel. The io module should be rock-solid, with very deeply
documented semantics, and implementations that force platforms to
conform to these specifications. Eg. I've noticed that all io.FileIO
methods raised IOErrors in case of problem, except in one case (wrapping
a bad file decsriptor) where it's OSError - that little thing might make
big programs crash in an ugly way, if they only caught IOError.
I'm currently working on a cross-platform (linux, mac, windows at least)
FileIO type, with very strict semantics and extended abilities (file
range shared and exclusive locking, with timeouts) ; even though it'll
initially be slower than _fileio (most of it is in pure python), maybe
it might solve most of these io module problems. I'll keep people informed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Sep 18 20:44:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Sep 2009 18:44:26 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1253299466.33.0.769644185366.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for trunk's Objects/intobject.c.  With this patch, I'm 
seeing more than 100% speed increases for str(sys.maxint) on OS X 10.6 
(64-bit) and more modest speed gains on OS X 10.5 (32-bit).

I'm leaving out the two-digits-at-a-time optimization.  It *does* give a 
small speed gain on my machine, but IMO it's not enough of a gain to 
justify the extra code complexity;  it also seems like one of those 
optimizations whose value might be highly machine/compiler-dependent.

I'll apply this in a few days' time.

----------
Added file: http://bugs.python.org/file14924/int_decimal_conversion_trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:21:15 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Sep 2009 19:21:15 +0000
Subject: [issue6940] cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2
In-Reply-To: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za>
Message-ID: <1253301675.43.0.267059856835.issue6940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Works for me (2.6.2 tarball, 10.5.8 PPC, gcc build 5493).

Check configure.log and search for the failing "wchar_t" section.  Also, 
try stripping your $PATH down to bare essentials, removing /opt/local/bin 
(MacPorts), /sw/bin (Fink), /usr/local/bin, etc.; it's possible you're 
picking up an unexpected version of one of the build chain tools.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6940>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:40:16 2009
From: report at bugs.python.org (Rajarshi)
Date: Fri, 18 Sep 2009 19:40:16 +0000
Subject: [issue6940] cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2
In-Reply-To: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za>
Message-ID: <1253302816.18.0.0414877365669.issue6940@psf.upfronthosting.co.za>


Rajarshi <rajarshi.guha at gmail.com> added the comment:

Thanks for the pointer. Indeed, clearing PATH to the minimal set of
paths allows configure to complete.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6940>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:46:42 2009
From: report at bugs.python.org (Jeff Bradberry)
Date: Fri, 18 Sep 2009 19:46:42 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253303202.18.0.0643573803405.issue6300@psf.upfronthosting.co.za>


Jeff Bradberry <jeff.bradberry at gmail.com> added the comment:

Ok, fixed.  I am kind of vague, though, on the usefulness of str.encode
and unicode.decode.

----------
Added file: http://bugs.python.org/file14925/python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:48:26 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Sep 2009 19:48:26 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253303306.38.0.548847172669.issue5042@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I've commited a slightly changed patch plus a test.

trunk: 74917, py3k: 74918, release26-maint: 74919, release31-maint: 74920.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:48:44 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Sep 2009 19:48:44 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1253303324.43.0.540054654448.issue5042@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:58:13 2009
From: report at bugs.python.org (Joshua Purcell)
Date: Fri, 18 Sep 2009 19:58:13 +0000
Subject: [issue6941] Help
Message-ID: <1253303892.82.0.946602565128.issue6941@psf.upfronthosting.co.za>


Changes by Joshua Purcell <spamail.08jpurcellserver at gmail.com>:


----------
nosy: 08jpurcell
severity: normal
status: open
title: Help
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Fri Sep 18 21:59:22 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 18 Sep 2009 19:59:22 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1253303202.18.0.0643573803405.issue6300@psf.upfronthosting.co.za>
Message-ID: <4AB3E6B8.1090602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jeff Bradberry wrote:
> 
> Jeff Bradberry <jeff.bradberry at gmail.com> added the comment:
> 
> Ok, fixed.  I am kind of vague, though, on the usefulness of str.encode
> and unicode.decode.

codecs can work on any combination of types. Here's an example of
a codec that accepts str and unicode and returns str:

'313233'
>>> u'123'.encode('hex')
'313233'
>>> '313233'.decode('hex')
'123'
>>> u'313233'.decode('hex')
'123'

In 3.1 the method don't support this anymore, since they are more
strict w/r to type checking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Fri Sep 18 22:00:50 2009
From: report at bugs.python.org (Joshua Purcell)
Date: Fri, 18 Sep 2009 20:00:50 +0000
Subject: [issue6941] Help
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>


New submission from Joshua Purcell <spamail.08jpurcellserver at gmail.com>:

My IDLE (Python GUI) Will NOT open It says socket error which is really 
annoying me because it doesnt open IDLE (AT ALL)

----------
components: +IDLE
type:  -> performance
Added file: http://bugs.python.org/file14926/python_icon.exe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Fri Sep 18 22:13:49 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Sep 2009 20:13:49 +0000
Subject: [issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't
	always result in NULL
In-Reply-To: <1228816020.28.0.155864486659.issue4606@psf.upfronthosting.co.za>
Message-ID: <1253304829.08.0.261002210054.issue4606@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Comitted as

trunk: 74921, py3k: 74922, release31-maint: 74923, release26-maint: 74924

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4606>
_______________________________________

From report at bugs.python.org  Fri Sep 18 22:19:08 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Sep 2009 20:19:08 +0000
Subject: [issue6613] ctypes.PyThreadState_SetAsyncExc does not work on linux
	64bit machines
In-Reply-To: <1249053223.75.0.703019238493.issue6613@psf.upfronthosting.co.za>
Message-ID: <1253305148.97.0.0266340500566.issue6613@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I guess this is a bug in your code, as mentioned in my last comment, so
closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6613>
_______________________________________

From report at bugs.python.org  Fri Sep 18 22:20:53 2009
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Sep 2009 20:20:53 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1253305253.9.0.295874459281.issue6729@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Find where c_size_t is defined: in Lib/ctypes/__init__.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Fri Sep 18 22:43:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Sep 2009 20:43:54 +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: <1253306634.98.0.629889201139.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a more careful patch for just the gamma function.  It's a fairly 
direct implementation of Lanczos' formula, with the choice of parameters 
(N=13, g=6.024680040776729583740234375) taken from the Boost library.  In 
testing of random values and known difficult values, it's consistently 
giving errors of < 5ulps across its domain.  This is considerably better 
than the error from the exp(lgamma(x)) method, since the exp call alone 
can easily introduce errors of hundreds of ulps for larger values of x.

I'd appreciate any feedback, especially if anyone has the chance to test 
on Windows:  I'd like to know whether I got the build modifications right.

This patch *doesn't* use the system gamma function, even when available.  
At least on OS X 10.5.8, the supplied gamma function has pretty terrible 
accuracy, and some severe numerical problems near negative integers.  I 
don't imagine Linux is much better.

Once this is working, I'll concentrate on lgamma.  Then erf and erfc.

----------
Added file: http://bugs.python.org/file14927/gamma3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Sep 18 23:02:46 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Sep 2009 21:02:46 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253307766.74.0.437454327203.issue6925@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

OK. Same is true of vars() also. So I suggest that current locals()
entry be changed to

"Update and return a dictionary representing the current local symbol
table. In function blocks, this includes nonlocal names.

Note
The contents of this dictionary should not be modified; changes may not
affect the values of local (or nonlocal) variables used by the interpreter."

and vars() first sentence be simplified to "Without arguments, same as
locals()." to follow the DRY principle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Fri Sep 18 23:15:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Sep 2009 21:15:37 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1253308537.34.0.109861027753.issue6300@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r74929. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Fri Sep 18 23:22:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 21:22:27 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253308947.03.0.146962570779.issue6925@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed now in r74930.  I kept "free variables" because this is
the correct term, while "nonlocals" clashes with the "nonlocal"
statement in 3.x.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Fri Sep 18 23:36:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 21:36:16 +0000
Subject: [issue6930] [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param)
In-Reply-To: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za>
Message-ID: <1253309776.89.0.0835355908839.issue6930@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I applied a slightly different patch in r74933.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6930>
_______________________________________

From report at bugs.python.org  Fri Sep 18 23:48:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Sep 2009 21:48:28 +0000
Subject: [issue6885] pdb documentation shows running as script using "python"
	not "python3"
In-Reply-To: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>
Message-ID: <1253310508.92.0.475577344368.issue6885@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Windows, 3.x has so far been installed as python.exe, not
python3.exe, so this change is not correct for Windows users. So please
consider reverting this until there is a consistent change across platforms.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6885>
_______________________________________

From report at bugs.python.org  Fri Sep 18 23:49:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Sep 2009 21:49:11 +0000
Subject: [issue6885] pdb documentation shows running as script using "python"
	not "python3"
In-Reply-To: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>
Message-ID: <1253310551.15.0.637226317598.issue6885@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I assume the poor Windows users can figure out what they need to do :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6885>
_______________________________________

From report at bugs.python.org  Sat Sep 19 00:32:36 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 18 Sep 2009 22:32:36 +0000
Subject: [issue6941] Help
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1253313156.06.0.677795117246.issue6941@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file14926/python_icon.exe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Sat Sep 19 00:34:21 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 18 Sep 2009 22:34:21 +0000
Subject: [issue6941] Socket error when launching IDL
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1253313261.89.0.0925654252065.issue6941@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Can you copy what is being printed out to a text file or into a comment on 
this issue? Also, what OS is this on? Otherwise we have nothing to work 
off of.

I also deleted whatever exe you uploaded as that will not help with 
debugging at all.

----------
nosy: +brett.cannon
title: Help -> Socket error when launching IDL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Sat Sep 19 00:37:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Sep 2009 22:37:51 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253313471.59.0.560578642744.issue6925@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I disagree with calling only nonlocal variables but not module variables
'free'. As I quoted from Wikipedia, that restrictive definition is not
agree on by all at all.  From The Free On-line Dictionary of Computing,
"1. A variable referred to in a function, which is not an argument of
the function. In lambda-calculus, x is a bound variable in the term M =
\ x . T, and a free variable of T. We say x is bound in M and free in T.
If T contains a subterm \ x . U then x is rebound in this term. This
nested, inner binding of x is said to "shadow" the outer binding.
Occurrences of x in U are free occurrences of the new x.
Variables bound at the top level of a program are technically free
variables within the terms to which they are bound but are often treated
specially because they can be compiled as fixed addresses. Similarly, an
identifier bound to a recursive function is also technically a free
variable within its own body but is treated specially."

Python does not treat top-level or recursive function names specially in
the way meant above.

I used 'nonlocal' specifically because the behavior of locals() seemed
by my testing to be concordant with the behavior of the 'nonlocal'
statement, which rejects the globals that locals does not print.  What
do you mean by 'clash'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Sat Sep 19 01:53:52 2009
From: report at bugs.python.org (Ross Patterson)
Date: Fri, 18 Sep 2009 23:53:52 +0000
Subject: [issue6942] email.generator.Generator memory consumption
In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
Message-ID: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>


New submission from Ross Patterson <me at rpatterson.net>:

Due to repeated use of StringIO as a way to "look ahead" into subparts 
while checking that multipart boundaries are unique, memory consumption 
during email.generator.Generator.flatten() can be up to 3 times the 
original message size.

I implemented a subclass of email.generator.Generator that works around 
this using email.message.Message.walk() to check message headers and 
string (final) payloads for the boundary without duplicating their 
contents into a StringIO.

It assumes that the boundary only ever might be duplicated in a single 
part's headers or in a single part's payload when that part's payload is 
a string.  IOW, it assumes that the boundary will not be duplicated by 
some combination of all the parts' and recursive subparts' headers and 
string payloads.

If this assumption is safe, then this implementation should work.  If 
this assumption is not safe, then perhaps a different boundary format 
can be used which will make this assumption safe?

You can find my implementation at http://gitorious.org/rpatterson-
imappipe/rpatterson-
imappipe/blobs/master/rpatterson/imappipe/generator.py

----------
components: Library (Lib)
messages: 92853
nosy: rpatterson
severity: normal
status: open
title: email.generator.Generator memory consumption
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6942>
_______________________________________

From report at bugs.python.org  Sat Sep 19 02:38:51 2009
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Sat, 19 Sep 2009 00:38:51 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1253320731.48.0.313425253817.issue1602@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Another note:
if one creates a dummy Stream object (having a softspace attribute and a
write method that writes using os.write, as in
http://stackoverflow.com/questions/878972/windows-cmd-encoding-change-causes-python-crash/1432462#1432462
) to replace sys.stdout and sys.stderr, then writes occur correctly,
without issues. Pre-requisites:
chcp 65001, Lucida Console font and cp65001 as an alias for UTF-8 in
encodings/aliases.py
This is Python 2.5.4 on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Sep 19 04:14:45 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Sep 2009 02:14:45 +0000
Subject: [issue6743] pprint.pprint should support no objects to print blank
	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1253326485.11.0.906896982593.issue6743@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

And use keyword-only arguments :)

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Sat Sep 19 05:18:43 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Sep 2009 03:18:43 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I use --with-system-ffi option, but setup.py fails to find headers of
system libffi which are placed outside standard include directory,
which causes using of internal copy of libffi.

In Gentoo, headers of libffi-3.0.8 are installed into
/usr/lib/libffi-3.0.8/include directory, because their content is
specific to given architecture.

I'm attaching the patch which cause using of `pkg-config libffi --
(Unfortunately subprocess module cannot be used in setup.py, so I'm
using os.popen().)

----------
components: Build
files: python-fix_search_for_libffi_headers.patch
keywords: patch
messages: 92856
nosy: Arfrever, loewis
severity: normal
status: open
title: setup.py fails to find headers of system libffi
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/file14928/python-fix_search_for_libffi_headers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Sat Sep 19 05:21:31 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Sep 2009 03:21:31 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1253330491.13.0.331800088884.issue6943@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

It seems that a part of my comment has been truncated.
I meant `pkg-config libffi --cflags` command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Sat Sep 19 07:36:10 2009
From: report at bugs.python.org (Marien Zwart)
Date: Sat, 19 Sep 2009 05:36:10 +0000
Subject: [issue6944] socket.getnameinfo raises SystemError on bogus input
In-Reply-To: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za>
Message-ID: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za>


New submission from Marien Zwart <m_zwart at 123mail.org>:

socket.getnameinfo passes a PyObject* to PyArg_ParseTuple without
checking if it's a tuple first. That means it raises SystemError on
invalid input where TypeError would make more sense:

>>> socket.getnameinfo('localhost', 0)
SystemError: new style getargs format but argument is not a tuple

An explicit check for TypeError seems like the best way to fix this.
Patch (against Python 3.1.1, but it looked like this applies easily to
other branches too) attached, which also removes a bit of dead code.

----------
components: Extension Modules
files: diff.patch
keywords: patch
messages: 92858
nosy: marienz
severity: normal
status: open
title: socket.getnameinfo raises SystemError on bogus input
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14929/diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6944>
_______________________________________

From report at bugs.python.org  Sat Sep 19 08:11:14 2009
From: report at bugs.python.org (Marien Zwart)
Date: Sat, 19 Sep 2009 06:11:14 +0000
Subject: [issue6944] socket.getnameinfo raises SystemError on bogus input
In-Reply-To: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za>
Message-ID: <1253340674.18.0.201796688479.issue6944@psf.upfronthosting.co.za>


Marien Zwart <m_zwart at 123mail.org> added the comment:

Attaching a less broken patch, after Taggnostr pointed out on irc that
the code I removed is not actually dead. I really don't know why I
thought it was. I did take the opportunity to make it more obvious what
that code is actually checking for.

----------
Added file: http://bugs.python.org/file14930/diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6944>
_______________________________________

From report at bugs.python.org  Sat Sep 19 09:35:21 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 07:35:21 +0000
Subject: [issue6944] socket.getnameinfo raises SystemError on bogus input
In-Reply-To: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za>
Message-ID: <1253345721.08.0.883156537838.issue6944@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Adapted the test that expected the SystemError (?!) and committed in
r74943. Will backport to 2.6.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6944>
_______________________________________

From report at bugs.python.org  Sat Sep 19 09:43:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 07:43:28 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1253346208.81.0.833264463011.issue6943@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks OK and works on my system (the listcomp should be wrapped
though).

----------
assignee:  -> loewis
keywords: +easy
nosy: +georg.brandl
priority:  -> normal
stage:  -> patch review
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Sat Sep 19 09:48:01 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 07:48:01 +0000
Subject: [issue6942] email.generator.Generator memory consumption
In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
Message-ID: <1253346481.66.0.00439663198519.issue6942@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6942>
_______________________________________

From report at bugs.python.org  Sat Sep 19 11:26:59 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 19 Sep 2009 09:26:59 +0000
Subject: [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Currently pprint does not work on dicts it cannot sort.  Because in
Python 3 sorted(x.items()) is no longer guaranteed to work a new sorting
solution has to be found.

----------
messages: 92862
nosy: aronacher
severity: normal
status: open
title: pprint.pprint does not pprint unsortable dicts in Python 3
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________

From report at bugs.python.org  Sat Sep 19 11:35:44 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 19 Sep 2009 09:35:44 +0000
Subject: [issue6946] Document: Missing link to datetime.datetime
In-Reply-To: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za>
Message-ID: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Please see http://docs.python.org/genindex-D.html.

  "datetime (class in datetime), [1]"

links to same address. I think "[1]" should point to 
http://docs.python.org/library/datetime.html#datetime-datetime.

----------
assignee: georg.brandl
components: Documentation
messages: 92863
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: Document: Missing link to datetime.datetime
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6946>
_______________________________________

From report at bugs.python.org  Sat Sep 19 11:44:45 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 19 Sep 2009 09:44:45 +0000
Subject: [issue6947] Fix distutils test on windows (SO extension)
In-Reply-To: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za>
Message-ID: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This will fix distutils test error on windows.

----------
assignee: tarek
components: Distutils, Tests
files: test_distutils.patch
keywords: patch
messages: 92864
nosy: ocean-city, tarek
severity: normal
status: open
title: Fix distutils test on windows (SO extension)
versions: Python 2.6
Added file: http://bugs.python.org/file14931/test_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6947>
_______________________________________

From report at bugs.python.org  Sat Sep 19 11:59:15 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 19 Sep 2009 09:59:15 +0000
Subject: [issue6947] Fix distutils test on windows (SO extension)
In-Reply-To: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za>
Message-ID: <1253354355.28.0.354612285638.issue6947@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done, thx

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6947>
_______________________________________

From report at bugs.python.org  Sat Sep 19 12:35:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 10:35:10 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253356510.16.0.813376788076.issue6925@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> I disagree with calling only nonlocal variables but not module variables
> 'free'. As I quoted from Wikipedia, that restrictive definition is not
> agree on by all at all.

But it is the definition that Python uses, at least in the code.  I
agree that the usage of "free variable" in the reference manual is
inconsistent; this should be fixed independently.

> Python does not treat top-level or recursive function names specially in
> the way meant above.

It does treat them differently: they are globals, not free variables.

> I used 'nonlocal' specifically because the behavior of locals() seemed
> by my testing to be concordant with the behavior of the 'nonlocal'
> statement, which rejects the globals that locals does not print.  What
> do you mean by 'clash'?

"nonlocal" variables could be mistaken as variables that are declared as
nonlocal by such a statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Sat Sep 19 12:43:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 10:43:04 +0000
Subject: [issue6946] Document: Missing link to datetime.datetime
In-Reply-To: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za>
Message-ID: <1253356984.91.0.27929106536.issue6946@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74952.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6946>
_______________________________________

From report at bugs.python.org  Sat Sep 19 15:11:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 13:11:50 +0000
Subject: [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253365910.93.0.26140811493.issue6945@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

A simple fix is to use key=lambda x: (id(type(x)), x).  However, that
obviously doesn't work with values of different, but orderable types.

At the moment, I don't see how the Python 2 sort could be implemented
without a cmp() argument to sorted().

----------
nosy: +georg.brandl
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________

From report at bugs.python.org  Sat Sep 19 15:56:36 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Sep 2009 13:56:36 +0000
Subject: [issue6941] Socket error when launching IDL
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1253368596.83.0.445493270361.issue6941@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Sat Sep 19 16:59:00 2009
From: report at bugs.python.org (kewlar)
Date: Sat, 19 Sep 2009 14:59:00 +0000
Subject: [issue6948] list
In-Reply-To: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za>
Message-ID: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za>


New submission from kewlar <bolshenog at bk.ru>:

>>> a = [[0,0,0],[0,0,0],[0,0,0]]
>>> a
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
>>> a[1][1] = 1
>>> a
[[0, 0, 0], [0, 1, 0], [0, 0, 0]]
>>> b = [[0]*3]*3
>>> b
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
>>> b[1][1] = 1
>>> b
[[0, 1, 0], [0, 1, 0], [0, 1, 0]]
>>>

----------
messages: 92869
nosy: nutregina
severity: normal
status: open
title: list
type: performance
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6948>
_______________________________________

From report at bugs.python.org  Sat Sep 19 17:05:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Sep 2009 15:05:53 +0000
Subject: [issue6948] list
In-Reply-To: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za>
Message-ID: <1253372753.6.0.869848841806.issue6948@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is not a bug in Python.  For general Python questions, please ask on 
comp.lang.python.

(If you weren't trying to report a bug in the first place, please could 
you explain your purpose in opening this issue.)

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6948>
_______________________________________

From report at bugs.python.org  Sat Sep 19 17:08:33 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Sep 2009 15:08:33 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1253372913.13.0.516182228763.issue6943@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file14932/python-fix_search_for_libffi_headers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Sat Sep 19 17:20:31 2009
From: report at bugs.python.org (chuck)
Date: Sat, 19 Sep 2009 15:20:31 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1253373631.8.0.631843413097.issue6941@psf.upfronthosting.co.za>


Changes by chuck <jan.hosang at gmail.com>:


----------
status: pending -> open
title: Socket error when launching IDL -> Socket error when launching IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Sat Sep 19 17:54:49 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Sep 2009 15:54:49 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1253375689.28.0.89556233083.issue6941@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Sat Sep 19 18:09:31 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Sep 2009 16:09:31 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python doesn't detect Berkeley DB 4.8. After updating setup.py, _bsddb
module fails to build due to some changes in Berkeley DB.

I'm attaching patch which seems to fix these problems.
Changes in setup.py were made by me.
Changes in Modules/_bsddb.c were copied from bsddb3-4.8.0 [1].

[1] http://www.jcea.es/programacion/pybsddb.htm

----------
components: Build
files: python-support_bdb-4.8.patch
keywords: patch
messages: 92871
nosy: Arfrever
severity: normal
status: open
title: Support Berkeley DB 4.8
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14933/python-support_bdb-4.8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Sat Sep 19 18:16:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Sep 2009 16:16:45 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1253377005.66.0.244658309376.issue6949@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> jcea
nosy: +jcea
priority:  -> normal
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Sat Sep 19 18:24:21 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 19 Sep 2009 16:24:21 +0000
Subject: [issue6950] online documentation error: PyObject*
	PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
In-Reply-To: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za>
Message-ID: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

according to bytearrayobject.c, PyByteArray_Resize should return int (not 
PyObject *)

error found @
http://docs.python.org/dev/py3k/c-api/bytearray.html
http://docs.python.org/c-api/bytearray.html

----------
assignee: georg.brandl
components: Documentation
messages: 92872
nosy: georg.brandl, kaizhu
severity: normal
status: open
title: online documentation error: PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6950>
_______________________________________

From report at bugs.python.org  Sat Sep 19 18:26:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Sep 2009 16:26:52 +0000
Subject: [issue6950] online documentation error: PyObject*
	PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
In-Reply-To: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za>
Message-ID: <1253377612.76.0.416544968002.issue6950@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a duplicate of #6881.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6950>
_______________________________________

From report at bugs.python.org  Sat Sep 19 19:01:07 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sat, 19 Sep 2009 17:01:07 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1253379667.65.0.169299184535.issue6839@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I added a patch to replace back slashes by forward slashes in three 
places, only one if them actually relevant to the errors in the attached 
.zip file.

I kept the exception for mismatching filenames, but if you think it is 
appropriate to remove it I could do that as well.

----------
keywords: +patch
nosy: +chuck
Added file: http://bugs.python.org/file14934/zlib_forward_slash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6839>
_______________________________________

From report at bugs.python.org  Sat Sep 19 21:07:43 2009
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 19 Sep 2009 19:07:43 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253387263.23.0.00128091311655.issue6918@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

This one is fixed, isn't it?

See for example the buildbot output at

http://www.python.org/dev/buildbot/2.6/builders/x86%20osx.5%202.6/builds/566/steps/compile/logs/stdio

(Search for "building '_ctypes' extension" on the page)

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Sat Sep 19 22:36:22 2009
From: report at bugs.python.org (Gawain Bolton)
Date: Sat, 19 Sep 2009 20:36:22 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1253392582.59.0.0284642146169.issue6713@psf.upfronthosting.co.za>


Gawain Bolton <gp.bolton at computer.org> added the comment:

Here's a modified version of the patch to Objects/intobject.c which
__does__ use the two-digits-at-a-time optimization.

Compared to the int_decimal_conversion_trunk.patch, my tests show a
further 12.5% improvement with two digit numbers - positive or negative
and more than 8% overall using different sizes all the way up to sys.maxint.

I admit, there is a slight increase in code complexity.  However, I
disagree that the optimization is machine/compiler dependent as there
are fundamentally half as many divisions.

I hope I don't come across as unappreciative, on the contrary the
fundamental ideas is to special case base 10 conversions and get a speed
boost by leveraging the compiler and the
int_decimal_conversion_trunk.patch does this nicely.

I do think it would be unfortunately to not go a little further though -
just because we can do better with little effort, we can save a few CPU
cycles which means saving time, money and all of this can only be good
for the planet.  ;-)

----------
Added file: http://bugs.python.org/file14935/int_decimal_conversion_trunk.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sat Sep 19 22:38:04 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 19 Sep 2009 20:38:04 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1253392684.2.0.0584656792174.issue3890@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Wouldn't it be nice to add a test for this case, to demonstrate that
non-blocking reads really are possible?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Sat Sep 19 23:13:28 2009
From: report at bugs.python.org (Sriram)
Date: Sat, 19 Sep 2009 21:13:28 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1253394808.86.0.131226385656.issue5727@psf.upfronthosting.co.za>


Sriram <sriramrathinavelu at yahoo.com> added the comment:

Hi,

How about changing pdb's behavior, that it disables readline only if the 
passed stream is not the stdout stream?

Also when looking at doctest module, I found that bdb's trace_dispatch 
was overridden to set the debugger's output stream to something other 
than stdout. I presume, that since prior to 2.5, pdb never took the 
stdin and stdout arguments and that overridden method was needed to make 
pdb use a stream other than stdout, but now that 2.5 allows us to pass 
the output stream in init method of pdb, that function is no longer 
needed.

Thanks

----------
nosy: +sriram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5727>
_______________________________________

From report at bugs.python.org  Sun Sep 20 00:32:11 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Sep 2009 22:32:11 +0000
Subject: [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253399531.96.0.926786731762.issue6925@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My point was and is that global variables *are* free variables by the
definition I learned and that I quoted and that in the absence of an
'official' and consistent definition for the purpose of the manual,
(linked to from its usages) people can and probably will be confused as
I was. I will leave this at that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________

From report at bugs.python.org  Sun Sep 20 04:19:52 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 20 Sep 2009 02:19:52 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1253413192.99.0.00211883697958.issue6869@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope attached patch will fix this issue.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file14936/fix_ctypes_crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6869>
_______________________________________

From report at bugs.python.org  Sun Sep 20 09:00:31 2009
From: report at bugs.python.org (aaditya sood)
Date: Sun, 20 Sep 2009 07:00:31 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253430031.93.0.656284902643.issue6937@psf.upfronthosting.co.za>


aaditya sood <aaditya at sood.net.in> added the comment:

Ronald, if you can also put the magic incantations on a wiki page
somewhere it'd really help me out. I can then download 2.6.2 and build
it for snow leopard. 

I can put up a downloadable version for other people if needed.

I'm assuming this will bite a lot of people on snow leopard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Sun Sep 20 09:24:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Sep 2009 07:24:45 +0000
Subject: [issue6881] incorrect signature in doc for PyByteArray_Resize
In-Reply-To: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>
Message-ID: <1253431485.71.0.487234795837.issue6881@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r74958 (trunk), r74959 (release26-maint), r74960 (py3k) and
r74961 (release31-maint).

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6881>
_______________________________________

From report at bugs.python.org  Sun Sep 20 10:05:17 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Sep 2009 08:05:17 +0000
Subject: [issue6951] OS X IDLE has two Preferences menus on 2.6.x with Tk >
	8.4.7
In-Reply-To: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>
Message-ID: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Release blocker

On OS X IDLE 2.6 shows two Preference menu items, the second dimmed out, 
but only when running with an installed Tk 8.4 > 8.4.7.

This is the same problem identified in Issue6100 and was fixed in trunk 
but not backported.  Now that the Apple-supplied 8.4 Tk in 10.6 is 8.4.19, 
the problem is more serious on 2.6.  The attached patch backports r72946 
from trunk.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
files: patch-nad0027-26.txt
messages: 92883
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X IDLE has two Preferences menus on 2.6.x with Tk > 8.4.7
versions: Python 2.6
Added file: http://bugs.python.org/file14937/patch-nad0027-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6951>
_______________________________________

From report at bugs.python.org  Sun Sep 20 10:57:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Sep 2009 08:57:27 +0000
Subject: [issue6951] OS X IDLE has two Preferences menus on 2.6.x with Tk >
	8.4.7
In-Reply-To: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>
Message-ID: <1253437047.21.0.805950947143.issue6951@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
keywords: +easy
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6951>
_______________________________________

From report at bugs.python.org  Sun Sep 20 11:05:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Sep 2009 09:05:00 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1253437500.87.0.00868003068925.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I do think it would be unfortunately to not go a little further though -
> just because we can do better with little effort, we can save a few CPU
> cycles which means saving time, money and all of this can only be good
> for the planet.  ;-)

Gawain,

Programmer cycles matter too. :-)   Code clarity, especially in the Python 
core, is valued (at least by me) very highly---for all the usual reasons:  
readability, maintainability, fewer places for bugs to hide.  Verifying 
the correctness of the shorter version of int_to_decimal_string takes 
significantly less time, for me, than verifying the longer version.  Of 
course, that's probably partly because I wrote it, but I'd guess that it's 
still true for an independent viewer.

For example, Tim Peters has been heard to say that if he did this all over 
again, he probably wouldn't have added Karatsuba multplication:

http://mail.python.org/pipermail/python-dev/2008-November/083355.html

It's not easy deciding where to draw the line, but for me, this particular 
tiny speed gain (12.5% on a microbenchmark isn't really that significant) 
just isn't worth this particular (also tiny, admittedly) complexity gain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sun Sep 20 11:13:42 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Sep 2009 09:13:42 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253438022.87.0.629831582609.issue6864@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Here's a status update:

After testing 2.6.3-pre-rc1 with various combinations of Apple and 
ActiveState Tk 8.4 and 8.5 on 10.5 and 10.6, so far I have only seen the 
"new window hang" problem with Apple's Tk 10.5 (10.5.7) as supplied with 
10.6 Snow Leopard.  Although the Apple-supplied 2.6.1 IDLE runs in 64-
bit, the same hang shows up with Apple Tk 8.5.7 in 32-bit mode as well 
(this with a 32-bit 2.6-svn IDLE built on 10.5 in the manner of the 
standard python.org installers except with AS 8.5 Tk installed during 
the build).  Running this last installer on either 10.6 or 10.5 with AS 
8.5.7 installed (32-bit only), I have been unable to reproduce the "new 
window hang".  However, there are some other serious issues that I am 
still investigating.

The good news is that, so far with one exception and with admittedly 
light testing, I have seen no regressions on either 10.6 or 10.5 using 
Tk 8.4 with 2.6 svn: Apple Tk 10.4.19 on 10.6, Apple Tk 10.4.7 on 10.5, 
AS Tk 10.4.19 on either 10.5 or 10.6.  The exception is documented in 
Issue6951 with a supplied patch that should be go into 2.6.3.

Even without the Tk problems, it is also unfortunate for IDLE users that 
the Snow Leopard Python is 2.6.1; a number of problems with IDLE on OSX 
were fixed in 2.6.2.

So, with more work to be done, my recommendation at this point is to 
assume 2.6.3 can be released with an OS X installer dynamically linked 
as in the past with Tk 8.4 (so usable with either the system Tk 8.4 or a 
user-installed AS 8.4) and deployable on 10.3.9 through 10.6 on 32-bit 
Intel and PPC, where applicable.  Pending further investigation and 
resolution, we should say that 2.6.3 does not support Tk 8.5 on OS X - 
period.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 11:30:36 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 09:30:36 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253439036.0.0.0363374123464.issue6918@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thomas: I haven't fixed anything yet.

The error only happens when building a PPC binary (either a single-
architecture build on a PPC machine or a fat binary).

The error occurs in assembly files that contain manually constructed C++ 
exception stack unwind helper segments, I guess those are not entirely 
valid and the linker got more strict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Sun Sep 20 12:58:25 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 10:58:25 +0000
Subject: [issue6851] urllib.urlopen crashes in a thread on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1253444305.63.0.586737575926.issue6851@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch was not 100% correct in the error handling in the 
set_proxies functions. That is fixed in the actually commit.

Committed as r74962 (trunk), r74963 (2.6).

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________

From report at bugs.python.org  Sun Sep 20 13:00:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 11:00:49 +0000
Subject: [issue5413] urllib ctypes error on Mac OS X Server 10.5
In-Reply-To: <1236124544.96.0.577290884621.issue5413@psf.upfronthosting.co.za>
Message-ID: <1253444449.69.0.187636342876.issue5413@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've just committed a fix for another issue and that completely removes 
the ctypes-based code that causes this issue (replacing it by a C 
extension)

Therefore this issue should no longer occur and hence can be closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5413>
_______________________________________

From report at bugs.python.org  Sun Sep 20 13:28:51 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 11:28:51 +0000
Subject: [issue6934] [PATCH] postflight.framework script (from the Mac OS X
	.dmg installer) fails.
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253446131.33.0.202856708141.issue6934@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've fixed this issue in all 4 active branches.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior
versions: +Python 2.6, Python 2.7 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________

From report at bugs.python.org  Sun Sep 20 13:29:46 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 20 Sep 2009 11:29:46 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

Many Python API functions are causing GCC to rightly complain
that const char * strings are being passed to python functions
that take char * but do not need to modify the args.

g++ reports example.cxx:633: warning: deprecated conversion from string
constant to ?char*?

The example I encountered today, while testing PyCXX against
G++ 4.2.1 on Mac OS X, was PyObject_CallMethod
but it is not limited to this function.

Would a patch help progress this issue?

----------
components: Interpreter Core
messages: 92890
nosy: barry-scott
severity: normal
status: open
title: deprecated conversion from string constant to char *
type: compile error
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sun Sep 20 14:16:27 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sun, 20 Sep 2009 12:16:27 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253448987.0.0.991144296533.issue6864@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

I don't understand the logic of saying that IDLE in Python 2.6.3 will not 
support Tk 8.5 in any fashion when you say that it runs fine with 
ActiveState Tk 8.5. 8.4 is obsolete. The "new window hang" bug is specific 
to the version of Tk 8.5.7. If ActiveState's build works, then why not say 
you need to install your own version of Tk 8.5 for it to work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 14:27:36 2009
From: report at bugs.python.org (Marcin Wider)
Date: Sun, 20 Sep 2009 12:27:36 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1253449656.2.0.804722961091.issue5080@psf.upfronthosting.co.za>


Changes by Marcin Wider <mwider at gmail.com>:


----------
nosy: +marcin.wider

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Sun Sep 20 15:27:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 13:27:30 +0000
Subject: [issue6937] multiprocessing lock on OS X Snow Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253453250.81.0.232117112384.issue6937@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

To build universal build of Python use "--enable-universalsdk" or "--
enable-universalsdk=/" (the former defaults to the 10.4 SDK, which 
doesn't support a 64-bit build).  You can then use the "--with-
universal-archs" option to select the type of build you want.

Anyway, I can confirm that this does not affect either the trunk or the 
HEAD of release26-maint.

Closing this issue as out of date.


aaditya: you don't have to provide a seperate build for 10.6. Python 
2.6.3 will be released soon and we will ship a Mac installer for that.

As an aside: never replace /System/Library/Framework/Python.framework by 
something else. Apple ships a patched version of Python and replacing 
the system version might break the system or 3th-party applications.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________

From report at bugs.python.org  Sun Sep 20 16:13:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 14:13:32 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The documentation for the readline module is a bit too minimal.

1) function 'add_history' is described at the end of the documentation,
   not near the other functions for manipulation the history stack.

2) the index for remove_history_item and replace_history_item is 0-
based,
   while the index for get_history_item is 1-based.

The latter is a confusing API in the underlying readline library and 
should IMO be described in Python's documentation.

(If readline were a new addition to the stdlib I'd prefer to fix the 
interface, but that would have too many backward compatibility issues at 
this point in time).

----------
assignee: georg.brandl
components: Documentation
messages: 92893
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: readline documenation needs work
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Sun Sep 20 16:18:27 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 14:18:27 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253456307.91.0.684326893408.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Mark: it turns out that GNU readline has a rather odd interface, only 
the index of get_history_item is 1-based, all others are 0-based. This 
is not mentioned in the documentation (neither that of the readline 
module or the GNU documentation).

I've attached a very minimal testcase for the history manipulation 
functions in the readline module that passes with GNU readline.

The tests now also pass using libedit emulation (after fixing the 
compilation issues noted by Zvezdan).

I'll file a new issue about the readline documentation, that's unrelated 
to getting libedit support into the repository.

----------
Added file: http://bugs.python.org/file14938/test_readline.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Sun Sep 20 16:53:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 14:53:49 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253458429.31.0.229576555389.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed my latest version of the patch as r74970 (trunk) and r74971 
(3.2)


Barry: what's your opinion on a backport of this to 2.6?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Sun Sep 20 16:54:09 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 14:54:09 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253458449.73.0.417815154918.issue6877@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
type: crash -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Sun Sep 20 16:55:54 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 14:55:54 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1253458554.98.0.207146460626.issue6872@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is a duplicate of issue 6877, I'm therefore closing this one.

I've just committed a slightly updated patch from that issue to the trunk 
and 3.2.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6872>
_______________________________________

From report at bugs.python.org  Sun Sep 20 17:02:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 15:02:16 +0000
Subject: [issue3962] single architecture framework build fails on OS X 10.5
In-Reply-To: <1222349749.71.0.779692324968.issue3962@psf.upfronthosting.co.za>
Message-ID: <1253458936.06.0.289837392948.issue3962@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should be fixed in the trunk and 2.6 branches due to autodetection of 
the -arch_only flag (which was needed for OSX 10.6 support)

----------
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3962>
_______________________________________

From report at bugs.python.org  Sun Sep 20 17:43:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 15:43:07 +0000
Subject: [issue6812] Snow Leopard python program fails because
	_PyType_Modified is missing from python framework
In-Reply-To: <1251757214.1.0.925595604794.issue6812@psf.upfronthosting.co.za>
Message-ID: <1253461387.93.0.115869037877.issue6812@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The value of sys.path is rather strange, it includes both the system 
Python.framework and one in /Library/Frameworks.

Have you installed a copy of Python (for example by using the 2.6.2 
installer on the Python.org website)? If so, have you added symbolic 
links  or a .pth file that adds bits of the system installation to that 
separate install?

On my system the sys.path for the Python in /Library does not contain 
bits of /System/Library, and neither does sys.path for Apple's install 
of Python refer to /Library/Frameworks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6812>
_______________________________________

From report at bugs.python.org  Sun Sep 20 18:37:42 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Sun, 20 Sep 2009 16:37:42 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253464662.53.0.754507307399.issue1766304@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I revised the patch for Python 3.1 and added notices to Misc/NEWS and
the range documentation.

(Changing Type to resource usage.)

----------
nosy: +lehmannro
type: feature request -> resource usage
Added file: http://bugs.python.org/file14939/range.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:00:23 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Sep 2009 17:00:23 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253466023.0.0.537400495115.issue6864@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

@Kevin: I didn't say it runs fine with ActiveState TK 8.5.7; that's what 
the "other serious issues" refer to.  I need to do some more work to 
isolate those problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:09:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Sep 2009 17:09:15 +0000
Subject: [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253466555.4.0.752227763252.issue6945@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it the same as #3976?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:10:21 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 20 Sep 2009 17:10:21 +0000
Subject: [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253466621.3.0.272521357876.issue6945@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Yes.  Appears to be related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:10:36 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 20 Sep 2009 17:10:36 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1253466636.13.0.788294641242.issue3976@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:10:55 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 20 Sep 2009 17:10:55 +0000
Subject: [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253466655.53.0.437918759491.issue6945@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Duplicate of #3976

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:11:13 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 20 Sep 2009 17:11:13 +0000
Subject: [issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253466673.82.0.245287991875.issue6945@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:17:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Sep 2009 17:17:53 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1253467073.91.0.465069147693.issue3976@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Also note that this patch will not sort sequences of mixed types where
some types are intercomparable "correctly" (in the way that Python 2
did), e.g. for

{1:2, 2:3, 'a':4, 1.5: 5}

the 1.5 key will not be placed between the 1 and 2 keys.

I'm not aware of a way to implement that behavior without support for a
general comparison function instead of a DSU key function.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:32:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Sep 2009 17:32:40 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1253467960.61.0.414157627021.issue3976@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm thinking that pprint should not try to sort unsortable items.

   try:
       items = sorted(items)
   except TypeError:
       items = list(items)

----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:35:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Sep 2009 17:35:08 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1253468108.76.0.978596738678.issue3976@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, there *is* a way.  Consider this:

class safe_key(object):
    __slots__ = ('obj',)

    def __init__(self, obj):
        self.obj = obj

    def __eq__(self, other):
        return self.obj.__eq__(other.obj)

    def __lt__(self, other):
        try:
            return self.obj < other.obj
        except TypeError:
            return id(type(self.obj)) < id(type(other.obj))


ls = [2, 1, 1.0, 1.5, 'a', 'c', 'b']
print(sorted(ls, key=safe_key))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:37:55 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 20 Sep 2009 17:37:55 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1253468275.69.0.0855105951811.issue3976@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

@Georg: Instead of catching a TypeError i would rather call __gt__ /
__lt__ directly and check for NotImplemented.  Python 2.x did not catch
TypeErrors either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Sun Sep 20 19:39:51 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 20 Sep 2009 17:39:51 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1253468391.68.0.469077199633.issue3976@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Eg, something like this:

class safe_key(object):

    __slots__ = ('obj',)

    def __init__(self, obj):
        self.obj = obj

    def __eq__(self, other):
        return self.obj.__eq__(other.obj)

    def __lt__(self, other):
        rv = self.obj.__lt__(other.obj)
        if rv is NotImplemented:
            rv = id(type(self.obj)) < id(type(other.obj))
        return rv


ls = [2, 1, 1.0, 1.5, 'a', 'c', 'b']
print(sorted(ls, key=safe_key))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Sun Sep 20 20:47:00 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sun, 20 Sep 2009 18:47:00 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1253472420.36.0.00622224500541.issue2504@psf.upfronthosting.co.za>


Changes by Christoph Zwerschke <cito at online.de>:


----------
nosy: +cito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sun Sep 20 20:59:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 18:59:32 +0000
Subject: [issue6918] ctypes compilation error on SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253473172.57.0.253587136331.issue6918@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've merged the latest copy of Apple's version of libffi into libffi_osx, 
that ensures that libffi compiles again on OSX 10.6.

Checked in in r74972 (trunk), r74973 (2.6), r74974 (3.x), r74975 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________

From report at bugs.python.org  Sun Sep 20 21:07:55 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 19:07:55 +0000
Subject: [issue6951] OS X IDLE has two Preferences menus on 2.6.x with Tk >
	8.4.7
In-Reply-To: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>
Message-ID: <1253473675.54.0.903183611053.issue6951@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've svnmerge-d the patch in r74976.

BTW. Thanks for checking the various Tk releases on 10.5/10.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6951>
_______________________________________

From report at bugs.python.org  Sun Sep 20 21:15:26 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 19:15:26 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253474126.87.0.794299040524.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree that we should mention in the news file that Apple's version of 
Tk 8.5 in Snow Leopard causes problems with IDLE.

W.r.t. Tk 8.4 vs. 8.5: the 2.6 binary releases will be linked to Tk 8.4 
because of two reasons. Firstly all 2.6 releases upto now were linked 
with Tk 8.4, and secondly IMO it is important that IDLE.app works out of 
the box on all supported OSX releases.

I'm willing to review patches for 2.7/3.2 that enable shipping two 
copies of _tkinter.so in the installer and automaticly selecting the 
best one at runtime (that is, ensure that import _tkinter imports the 
8.5 version when that is available and the 8.4 version otherwise).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 21:26:12 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 19:26:12 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253474772.29.0.184005776715.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

To explain my previous entry about shipping 8.4 and 8.5 versions of 
_tkinter, one way to implement this is:

* Build two copies of _tkinter.so: _tkinter84.so and _tkinter85.so
* Add _tkinter.py to Lib/plat-mac with the following contents:

    try:
       from _tkinter85 import *
    except ImportError:
       from _tkinter84 import *

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 21:44:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Sep 2009 19:44:16 +0000
Subject: [issue5764] 2.6.2 Python Manuals CHM file seems broken
In-Reply-To: <1239811108.5.0.558563747483.issue5764@psf.upfronthosting.co.za>
Message-ID: <1253475856.75.0.647335718593.issue5764@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

2.6.3 will be out soon with a valid chm again.

----------
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5764>
_______________________________________

From report at bugs.python.org  Sun Sep 20 22:10:24 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 20:10:24 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253477424.23.0.524876839161.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The problem is *not* reproducible using the trunk (2.7). 

I haven't been able to isolate the change that fixes the issue. As a 
quick hack I replaced _tkinter.so and Lib/idlelib/*.py in a 2.6 tree by 
the same files from the trunk. That didn't fix the issue, which probably 
indicates that some unrelated checkin accidently fixed the issue in the 
trunk.


Both the trunk and 2.6 have a menu named "IDLE" to the right and have 
"About Tcl/Tk" in the application menu. (This is when using Apple's Tk 
8.5 on OSX 10.6). That might be fixed by the patches in issue 6075.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 22:21:52 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 20:21:52 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253478112.85.0.771290961425.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm re-prioritizing this as "high" because the binary installer won't 
suffer from this issue and there is no straightforward bugfix.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Sun Sep 20 22:22:44 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 20:22:44 +0000
Subject: [issue6951] OS X IDLE has two Preferences menus on 2.6.x with Tk >
	8.4.7
In-Reply-To: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>
Message-ID: <1253478164.83.0.463079398677.issue6951@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6951>
_______________________________________

From report at bugs.python.org  Sun Sep 20 22:27:43 2009
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Sep 2009 20:27:43 +0000
Subject: [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

If you set the environment variable DISTUTILS_DEBUG=1, distutils will
run with DEBUG, which will trace internal activity.  But one of the
traces is incorrect, and leads to this stack trace: 

Traceback (most recent call last):
  File "setup.py", line 116, in <module>
    **more_setup_args
  File "c:\python31\lib\distutils\core.py", line 123, in setup
    dist.parse_config_files()
  File "c:\python31\lib\distutils\dist.py", line 357, in parse_config_files
    self.announce("  reading", filename)
  File "c:\python31\lib\distutils\dist.py", line 911, in announce
    log.log(level, msg)
  File "c:\python31\lib\distutils\log.py", line 31, in log
    self._log(level, msg, args)
  File "c:\python31\lib\distutils\log.py", line 20, in _log
    if level >= self.threshold:
TypeError: unorderable types: str() >= int()


The fix is simple: at line 356 of dist.py, change:

            if DEBUG:
                self.announce("  reading", filename)

to:
            if DEBUG:
                self.announce("  reading " + filename)

----------
assignee: tarek
components: Distutils
messages: 92916
nosy: nedbat, tarek
severity: normal
status: open
title: DISTUTILS_DEBUG causes stack trace, really simple fix
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________

From report at bugs.python.org  Sun Sep 20 22:50:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Sep 2009 20:50:33 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253479833.15.0.740927224167.issue6952@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A patch would definitely help. Such a patch shouldn't whole-sale replace
char with const char, but selectively only change locations where it is
actually necessary and doesn't hurt.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sun Sep 20 23:08:45 2009
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Sep 2009 21:08:45 +0000
Subject: [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253480925.09.0.14231889315.issue6954@psf.upfronthosting.co.za>


Ned Batchelder <nedbat at users.sourceforge.net> added the comment:

Another one:

Traceback (most recent call last):
  File "setup.py", line 72, in <module>
    **addl_args
  File "c:\python31\lib\distutils\core.py", line 149, in setup
    dist.run_commands()
  File "c:\python31\lib\distutils\dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "c:\python31\lib\distutils\dist.py", line 937, in run_command
    cmd_obj.ensure_finalized()
  File "c:\python31\lib\distutils\cmd.py", line 109, in ensure_finalized
    self.finalize_options()
  File "c:\python31\lib\distutils\command\install.py", line 315, in
finalize_options
    self.dump_dirs("pre-finalize_{unix,other}")
  File "c:\python31\lib\distutils\command\install.py", line 427, in
dump_dirs
    opt_name = opt_name.translate(longopt_xlate)
TypeError: 'function' object is not subscriptable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________

From report at bugs.python.org  Mon Sep 21 00:41:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 20 Sep 2009 22:41:35 +0000
Subject: [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253486495.44.0.185043927482.issue6954@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for noticing this. I'll add some test covering these and fix the
problems.

----------
priority:  -> normal
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________

From report at bugs.python.org  Mon Sep 21 05:03:06 2009
From: report at bugs.python.org (lovelygoo2)
Date: Mon, 21 Sep 2009 03:03:06 +0000
Subject: [issue6955] Max() Not Working Properly
In-Reply-To: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za>
Message-ID: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za>


New submission from lovelygoo2 <smergibblegibberish at usa.com>:

>>> max(['34', '7'])
'7'
>>> #This happens because it is comparing strings.
>>> #I have found a way to fix it though.
>>> def Max(li):
...    greatest=li[0]
...    for item in li:
...        for item2 in li:
...            if int(item)<int(item2) or int(item)<greatest:
...                break
...            else:
...                greatest=int(item)
...    return(greatest)

----------
components: IDLE
messages: 92920
nosy: lovelygoo2
severity: normal
status: open
title: Max() Not Working Properly
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6955>
_______________________________________

From report at bugs.python.org  Mon Sep 21 05:14:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Sep 2009 03:14:59 +0000
Subject: [issue6955] Max() Not Working Properly
In-Reply-To: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za>
Message-ID: <1253502899.95.0.337238532754.issue6955@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is the way strings are compared. You can change this easily,
though, using max(list_of_string_numbers, key=int).

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6955>
_______________________________________

From report at bugs.python.org  Mon Sep 21 05:17:36 2009
From: report at bugs.python.org (Leon Matthews)
Date: Mon, 21 Sep 2009 03:17:36 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1253503056.01.0.5472632369.issue6715@psf.upfronthosting.co.za>


Changes by Leon Matthews <leon at lost.co.nz>:


----------
nosy: +leonov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Sep 21 09:21:59 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 21 Sep 2009 07:21:59 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253517719.13.0.582769224456.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I tried to implement the new buffer API, but as soon as I add 
bf_getbuffer/bf_releasebuffer to PyBufferProcs writing an array to a file 
breaks:
  f.write(a)
  TypeError: must be contiguous buffer, not array.array

I searched through the file functions, but couldn't find the point where 
this happens. Has anybody a suggestion? Does file.write() use the old 
buffers? Doesn't it use reprfunc?

----------
nosy: +chuck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Mon Sep 21 11:26:56 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 09:26:56 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1253525216.74.0.71934978486.issue6864@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I also can verify that the problem is not reproducible using a current 
trunk (2.7) and the 10.6 Apple Tk 8.5.7.  Further testing of this issue 
with both Apple Tk 8.4.x and ActiveState Tk 8.4.19 on 10.4, 10.5, and 
10.6 has been hang-free.

It looks like there were a number of fixes to _tkinter.c and friends 
checked in by Guilherme early in 2009 that were not backported to 2.6 
and some of them have to do with thread locking.  Whether or not the 
fixes should have been backported is not an issue at this point. However 
I think it makes little sense to attempt much further work on this 
problem using the current 2.6 base without looking at backporting first.

So, with regard to the 2.6.3 release, I concur with Ronald's plan to 
continue to link only with Tk 8.4 for the OS X installer and I suggest 
there be a disclaimer somewhere about building with Tk 8.5 on OS X for 
2.6.3.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Mon Sep 21 11:34:17 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 09:34:17 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1253525657.46.0.340979869219.issue5120@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I noticed this while investigating Issue6834. Is this still an open issue 
for OS X?  Could it explain the symptoms in 6834?

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________

From report at bugs.python.org  Mon Sep 21 11:35:46 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 09:35:46 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1253525746.72.0.498172828443.issue5120@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, that should be Issue6864.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________

From report at bugs.python.org  Mon Sep 21 11:39:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Sep 2009 09:39:13 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253525953.6.0.0912182189181.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Robert,

The patch looks good: thank you.

Please use C89-style comments (/* ... */).

I'd like to see a few more tests covering the various combinations of
start less-than/equal-to/greater-than stop, step positive/negative, tested 
value within/without/at endpoints of the range interval, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Mon Sep 21 11:49:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Sep 2009 09:49:34 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253526574.68.0.0502999900691.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Also, it would be good to add a test or two for non-integers, e.g. to make 
explicit that the following behaviour hasn't changed:

>>> class C:
...     def __int__(self):  return 3
...     def __index__(self): return 5
...     def __eq__(self, other): return other == 4
... 
>>> C() in range(0, 10, 2)
True

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Mon Sep 21 12:45:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Sep 2009 10:45:24 +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: <1253529924.6.0.455265710371.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New patch for gamma , with some tweaks:

 - return exact values for integral arguments: gamma(1) through gamma(23)
 - apply a cheap correction to improve accuracy of exp and pow
   computations
 - use a different form of the reflection formula:

     gamma(x) = -pi/sinpi(x)/x/gamma(x)

   (the usual reflection formula has accuracy problems for
    x close to a power of 2;  e.g., x in (-64,-63) or x
    in (-128, -127))

 - avoid duplication formula for large negative arguments
 - add a few extra tests

On my machine, testing with approx. 10**7 random samples, this version 
achieves an accuracy of <= 10 ulps across the domain (comparing with 
correctly-rounded results generated by MPFR).  Limiting the test to 
arguments in the range (-256.0, 1/256.0] + [1/256.0, 256.0) (with each 
float in that range equally likely), the error in ulps from 10**6 samples 
has mean -0.104 and standard deviation 1.230.

I plan to check this in in a week or two.  Feedback welcome!  It would be 
especially useful to know whether this patch compiles correctly on 
Windows.

----------
keywords: +needs review
stage:  -> commit review
Added file: http://bugs.python.org/file14940/gamma4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 21 12:54:21 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 21 Sep 2009 10:54:21 +0000
Subject: [issue6956] Test creation in unittest.TestProgram should be done in
	one place
In-Reply-To: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za>
Message-ID: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Requested by Fernando Perez on the Testing in Python mailing list.

Test creation in TestProgram is done in both parseArgs and createTests.
It would be better if it was only done in createTests so that
controlling test creation only required the overloading of a single method.


> in TestProgram.parseArgs we have:
> 
>             if len(args) == 0 and self.defaultTest is None:
>                 self.test =
self.testLoader.loadTestsFromModule(self.module)
>                 return
> 
> and then later:
> 
>     def createTests(self):
>         self.test = self.testLoader.loadTestsFromNames(self.testNames,
>                                                        self.module)
> 
> So basically if you want to control how tests are created, you can't
just override createTests, because parseArgs also does test creation
> (but only sometimes, depending on certain conditions).

> I think that parseArgs should perhaps only parse args, and createTests
should only create tests, but I'm weird like that :)  For the case
> above, it could set a flag that createTests can then later use to
decide what to do, but parseArgs shouldn't be doing test creation IMO.

----------
assignee: michael.foord
components: Library (Lib)
messages: 92929
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: Test creation in unittest.TestProgram should be done in one place
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6956>
_______________________________________

From report at bugs.python.org  Mon Sep 21 13:06:00 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 11:06:00 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Potential 2.6.3 release blocker

On OS X 10.6 (Snow Leopard), if you attempt to install a package with a 
extension module using a Python from a python.org OS X installer (say, 
2.6.x or 3.1.x), the c compilation steps will likely fail in one of two 
ways:

1. Recent python.org installers are built using the OS X 10.4 SDK so 
that one installer image will work on 10.4, 10.5 and now 10.6 (in 
theory, 10.3.x as well).  Building of extension modules also require gcc 
and the SDKs, which are included as part of Apple's Xcode tools.  
However, with 10.6 Xcode, the 10.4 SDK is not installed by default so 
the extension module build will fail due to missing include files. Once 
the problem is known, it can be solved easily by installing the SDK from 
the release DVD that comes with the system or upgrade.

2. Even with the 10.4 SDK installed on 10.6, the compilation fails with:

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: 
stdarg.h: No such file or directory

This can be especially baffling to those unfamiliar with nested include 
files because the base file stdarg.h does exist in that directory.

The root cause here is that Snow Leopard now uses gcc-4.2 by default but 
the 10.4 SDK does not include headers for 4.2. The solution is to force 
use of gcc-4.0, the default on 10.4 and 10.5 and included in 10.6, by 
defining the CC environment variable:
 
  $ export CC=/usr/bin/gcc-4.0
  $ python setup.py install 
      or
  $ easy_install xxx

Even for experienced developers, these can be non-trivial problems to 
resolve although the solutions, once known, are easy to implement.  
Unfortunately, all types of python users can run into these issues 
simply by trying to install and use a package that includes an extension 
module.  There are a growing number of hits on the web from people 
trying to install popular packages such as MySQLdb, PIL, and lxml using 
a python.org Python on 10.6.  Note this isn't a problem for users of the 
Apple-supplied Pythons (2.6 and 2.5) on 10.6 since they do not use the 
10.4 SDK.

There are two separate issues here I think:
1. What, if anything, to do for users of installers already out in the 
field?
2. What to do to mitigate the problems for yet-to-be released installers 
(e.g. 2.6.3)?

Documenting and publicizing the problems somehow may be the only viable 
option for 1.  For 2, there is the possibility of some additional 
actions, perhaps a warning in the installer readme or some such.  It 
probably would make sense to contact the maintainers of such packages so 
that they can add something to their web pages and documentation.

----------
assignee: ronaldoussoren
components: Extension Modules, Macintosh
messages: 92930
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: Extension modules fail to build on OS X 10.6 using python.org 2.x/3.x
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Mon Sep 21 13:08:32 2009
From: report at bugs.python.org (Trundle)
Date: Mon, 21 Sep 2009 11:08:32 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253531312.98.0.320929638407.issue6952@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

See also issue #1699259.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Mon Sep 21 13:12:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 11:12:10 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253531530.1.0.336215871825.issue6957@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Mon Sep 21 13:23:17 2009
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 21 Sep 2009 11:23:17 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

I want the Python executable to have command line flags which allow
simple configuration of the logging module.  Use cases are to run
applications/scripts (which use libraries that use logging calls) with
different logging output without having to edit (ugly) logging config files.

The attached patch demonstrates the idea; it allows to run 'python -l
<options> ...' and passes <options> to a new function
logging._parse_python_options(<options>).

----------
components: Interpreter Core, Library (Lib)
files: logging.patch
keywords: patch
messages: 92932
nosy: theller
severity: normal
status: open
title: Add Python command line flags to configure logging
type: feature request
Added file: http://bugs.python.org/file14941/logging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 13:40:30 2009
From: report at bugs.python.org (Sebastian Ramacher)
Date: Mon, 21 Sep 2009 11:40:30 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253533231.0.0.655650061971.issue6952@psf.upfronthosting.co.za>


Changes by Sebastian Ramacher <sebastinas at users.sourceforge.net>:


----------
nosy: +sebastinas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Mon Sep 21 13:42:32 2009
From: report at bugs.python.org (Ding Xuan)
Date: Mon, 21 Sep 2009 11:42:32 +0000
Subject: [issue5764] 2.6.2 Python Manuals CHM file seems broken
In-Reply-To: <1253475856.75.0.647335718593.issue5764@psf.upfronthosting.co.za>
Message-ID: <ba178b2f0909210442m6b600f02k91359f8ff61717a3@mail.gmail.com>


Ding Xuan <dx617 at 163.com> added the comment:

thanks very much for your kindly notification :)

On Mon, Sep 21, 2009 at 3:44 AM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> 2.6.3 will be out soon with a valid chm again.
>
> ----------
> resolution:  -> later
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5764>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14942/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5764>
_______________________________________
-------------- next part --------------
thanks very much for your kindly notification :)<br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 3:44 AM, Georg Brandl <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Georg Brandl &lt;<a href="mailto:georg at python.org">georg at python.org</a>&gt; added the comment:<br>
<br>
2.6.3 will be out soon with a valid chm again.<br>
<br>
----------<br>
resolution: ??-&gt; later<br>
status: open -&gt; closed<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue5764" target="_blank">http://bugs.python.org/issue5764</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ding Xuan<br>

From report at bugs.python.org  Mon Sep 21 13:42:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Sep 2009 11:42:37 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253533357.35.0.18671894468.issue1766304@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As a small style note, I would prefer if the patch assigned in
conditionals less and split them out to the line before. I see that
rangeobject.c has a mixed style with regards to this, so the clearer one
should win! :)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Mon Sep 21 14:07:32 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 21 Sep 2009 12:07:32 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253534852.33.0.0484933668781.issue6958@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/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 14:15:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Sep 2009 12:15:38 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253535338.17.0.480765084938.issue6958@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vsajip
priority:  -> normal
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 14:21:57 2009
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 21 Sep 2009 12:21:57 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253535717.06.0.370221563627.issue6958@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/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 14:58:48 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 21 Sep 2009 12:58:48 +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: <1253537928.62.0.862203344625.issue3366@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I'll test your patch on Windows.  Are you working against the trunk or
the py3k branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 21 15:04:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Sep 2009 13:04:32 +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: <1253538272.97.0.0466009187994.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks!  The patch is against the trunk.  (It doesn't quite apply cleanly 
to py3k, but the changes needed to make it do so should be minimal.)

Hmm. Rereading my previous comment, I seem to have a blindness for 
negative signs:

    gamma(x) = -pi/sinpi(x)/x/gamma(x)

should have been

    gamma(-x) = -pi/sinpi(x)/x/gamma(x)

and

    (-256.0, 1/256.0] + [1/256.0, 256.0)

should have been

    (-256.0, -1/256.0] + [1/256.0, 256.0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 21 15:11:14 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Sep 2009 13:11:14 +0000
Subject: [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253538674.29.0.168577086488.issue6954@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Mmm, the problem is deeper for the second stack trace: 

distutils.fancy_getopt.longopt_xlate was changed from a translation
mapping into a lambda in py3, that's why you have it.

I'm fixing back this problem too.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________

From report at bugs.python.org  Mon Sep 21 15:23:15 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Mon, 21 Sep 2009 13:23:15 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253539395.83.0.421658503423.issue6952@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I'd guess that this change can first be made against 2.7 and 3.2
so that API's do not change.

Where do I find the source code to generate the patch against
for 2.7 and 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Mon Sep 21 15:37:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Sep 2009 13:37:58 +0000
Subject: [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253540278.86.0.591700584959.issue6954@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________

From report at bugs.python.org  Mon Sep 21 15:47:36 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 21 Sep 2009 13:47:36 +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: <1253540856.03.0.57638778958.issue3366@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I'm only setup to test the official Windows build setup under PCbuild. 
I'm not testing the legacy build setups under PC/VC6, PC/VS7.1, or PC/VS8.0.

The patch against the trunk failed for PC/VC6/pythoncore.dsp.  I don't
need that to build, though.

Your patch built fine, with one warning about a loss of precision on the
following line in sinpi():

    n = round(2.0*y);

I recommend explicitly casting the result of round() to int, to get rid
of the warning and because explicit is better than implicit. :)

I ran the following tests, all of which passed:

PCbuild/python.exe Lib/test/regrtest.py -v test_math

I appreciate your work on this patch.  Let me know if there's anything
else I can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 21 15:55:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Sep 2009 13:55:25 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253541325.2.0.983663915476.issue6952@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Take a look at http://www.python.org/dev, specifically the 'How to Get
Started' article (which points you to the developer's FAQ, which
explains how to do an anonymous checkout of the source).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Mon Sep 21 16:01:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Sep 2009 14:01:11 +0000
Subject: [issue6954] DISTUTILS_DEBUG causes stack trace, really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253541671.03.0.493571347786.issue6954@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Everything is covered now, and the mentioned bug is fixed in 
trunk (r74994), py3k (r74999) and release31 (75000).

Thanks !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________

From report at bugs.python.org  Mon Sep 21 16:02:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Sep 2009 14:02:37 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253541757.51.0.0478105253268.issue6952@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm setting the targets to 2.7/3.2 per the discussion in issue #1699259.
 Perhaps the question of whether or not it is "really" an API change
could be revisited, but if so that would probably have to go through
python-dev.

----------
priority:  -> normal
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Mon Sep 21 16:08:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Sep 2009 14:08:02 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1253542082.46.0.583500424779.issue1699259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 6952, which seems to be a broader request of the same
nature.  Moving the 3.1 target to 3.2, since 3.1 is out.

----------
nosy: +r.david.murray
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Mon Sep 21 16:30:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Sep 2009 14:30:55 +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: <1253543455.51.0.608919215107.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Many thanks, Daniel.

> The patch against the trunk failed for PC/VC6/pythoncore.dsp.  I don't
> need that to build, though.

I've no idea why that would happen.  A line-ending issue, perhaps?  If 
it doesn't stop me committing the change, then perhaps it's not a 
problem.

> Your patch built fine, with one warning about a loss of precision on
> the following line in sinpi():
>
>    n = round(2.0*y);
>
>I recommend explicitly casting the result of round() to int, to get
>rid of the warning and because explicit is better than implicit. :)

Done.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 21 18:32:16 2009
From: report at bugs.python.org (steve21)
Date: Mon, 21 Sep 2009 16:32:16 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1253550736.73.0.277277092619.issue3451@psf.upfronthosting.co.za>


Changes by steve21 <steve872929-bv at yahoo.com.au>:


----------
nosy: +steve21

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Sep 21 18:59:44 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 21 Sep 2009 16:59:44 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253552384.82.0.704979112175.issue6958@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I get the idea. The Python part of the patch demonstrates what you're
getting at, though it can't be used as is - for example the
getattr(logging, a, a) could lead to problems. However a more
intelligent parser (which looked for specific keywords recognised by
basicConfig(), and got the correct values accordingly) wouldn't be much
more complicated. (I'll look at enhancing this part.)

As for the changes to main.c - I am a C/C++ developer but have not made
any changes to Python C code so far - it would be good if a more
experienced committer reviews this part (not sure who - can someone
please reassign/add to nosy list)? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 19:15:58 2009
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 21 Sep 2009 17:15:58 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253552384.82.0.704979112175.issue6958@psf.upfronthosting.co.za>
Message-ID: <4AB7B4CA.3050904@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> I get the idea. The Python part of the patch demonstrates what you're
> getting at, though it can't be used as is - for example the
> getattr(logging, a, a) could lead to problems. However a more
> intelligent parser (which looked for specific keywords recognised by
> basicConfig(), and got the correct values accordingly) wouldn't be much
> more complicated. (I'll look at enhancing this part.)
> 
> As for the changes to main.c - I am a C/C++ developer but have not made
> any changes to Python C code so far - it would be good if a more
> experienced committer reviews this part (not sure who - can someone
> please reassign/add to nosy list)? Thanks.

Both parts of the patch are only thought to demonstrate the idea.
You said you'll attack the Python part - good.

For the C part, the most prominemt things that are missing are these:

- free(logopt) should be called at the end of the 'if (logopts != NULL) {' block.

- error handling should be improved.  Errors in this block should probably exit Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 19:34:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 17:34:03 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253554443.59.0.0310705143895.issue6958@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If you want to add flags to the main executable, it deserves a
discussion on python-dev IMO.
It could be obtained through an environment variable, e.g.
PYLOGGING_CONFIG; which has the nice side-effect of working for
executable scripts too.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 19:56:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Sep 2009 17:56:33 +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: <1253555793.95.0.95453558004.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

gamma5.patch.  very minor changes from the last patch:

 - add (int) cast suggested by Daniel Stutzbach
 - Misc/NEWS entry
 - ..versionadded in docs
 - minor corrections to some comments

----------
Added file: http://bugs.python.org/file14943/gamma5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 21 20:23:02 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 21 Sep 2009 18:23:02 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253557382.77.0.521538704476.issue6958@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The C code looks basically okay to me. I'd probably use strdup() instead
of the malloc/strlen/strcpy calls. And as Thomas said, the cleanup needs
a little bit of work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 20:31:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Sep 2009 18:31:01 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253557861.96.0.734482647968.issue6958@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Also possibly relevant was the recent python-dev discussion about
replicating (some of) the command line argument parsing in python so
that it can be used by things other than the 'python' command:

http://mail.python.org/pipermail/python-dev/2009-August/091484.html

----------
nosy: +ncoghlan, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 20:43:34 2009
From: report at bugs.python.org (egreen)
Date: Mon, 21 Sep 2009 18:43:34 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1253558614.55.0.0281537157142.issue6236@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

The problem is that the fileio struct in Modules/_io/fileio.c defines
the 2-bit seekable field as int.

>From the C99 standard, ?6.7.2: for bit-fields, it is
implementation-defined whether the specifier int designates the same
type as signed int or the same type as unsigned int.

Contrary to gcc, both xlc and suncc default to unsigned.

Adding 'signed' solves the problem (and also issue #6348).

Patch attached.

----------
nosy: +egreen
Added file: http://bugs.python.org/file14944/fileio-seekable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Mon Sep 21 20:44:23 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Sep 2009 18:44:23 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253558663.29.0.396434805982.issue6958@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Also, don't forget to update the "python -h" help text.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 20:46:12 2009
From: report at bugs.python.org (cscscs)
Date: Mon, 21 Sep 2009 18:46:12 +0000
Subject: [issue6959] OS X 10.6 / Snow Leopard
Message-ID: <1253558772.91.0.545762042171.issue6959@psf.upfronthosting.co.za>


Changes by cscscs <chris at schleiermachers.de>:


----------
nosy: cscscs
severity: normal
status: open
title: OS X 10.6 / Snow Leopard
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6959>
_______________________________________

From report at bugs.python.org  Mon Sep 21 20:47:38 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 21 Sep 2009 18:47:38 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253558858.65.0.916063788088.issue6958@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Why does this need to be built into the interpreter? The script / app
should have logging config support.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 22:06:05 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 20:06:05 +0000
Subject: [issue6959] OS X 10.6 / Snow Leopard: building 2.6 maintenance
	release fails for some modules (architecture issue)
In-Reply-To: <1253558979.67.0.56410771712.issue6959@psf.upfronthosting.co.za>
Message-ID: <1253563565.78.0.265661705568.issue6959@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

By default on 10.6, gcc builds in 64-bit mode. Nav is one of the 
deprecated "classic" Macintosh platform modules and has been removed in 
Python 3.  It and many other of the deprecated Mac modules use Carbon 
interfaces that are only available in 32-bit on OS X.  If you don't plan 
to use Nav and other Carbon Mac modules, you can ignore the build errors 
about Nav (although it would be nice to make it fail a bit more 
cleanly), otherwise force the build to be 32-bit only.  Also, OS X does 
not provide a GNU readline library; if you want to use it with your 
Python, you'll need to install a local copy (for example, via MacPorts 
or building your own); otherwise you can ignore that error as while.  In 
other words, other than those missing libraries, the python you built 
should work.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6959>
_______________________________________

From report at bugs.python.org  Mon Sep 21 22:16:47 2009
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 21 Sep 2009 20:16:47 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253558858.65.0.916063788088.issue6958@psf.upfronthosting.co.za>
Message-ID: <4AB7DF28.9080709@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> Why does this need to be built into the interpreter? The script / app
> should have logging config support.

It does not need to, but it would be nice.
I think the '-l' flag should be similar to the -W flag.
Or consider for example using unittest.main() as script/app.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 22:32:13 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 21 Sep 2009 20:32:13 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253565133.98.0.0126901952956.issue6958@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

If we do include interpreter support, there should be an option to
invoke a configuration file, too:

-l config=path

Mutually exclusive with all the other options. So, you can either use it
to invoke basicConfig or to invoke an arbitrary configuration in a file.

Opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 22:45:54 2009
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 21 Sep 2009 20:45:54 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253565954.15.0.592557538468.issue6958@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

I think I'm with Michael on this one.  I'd rather add logging
configuration to any stdlib modules that support being run directly and
want to support logging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 22:58:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Sep 2009 20:58:35 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253566715.64.0.253946245132.issue6958@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think this is about logging in stdlib modules that are run
directly. I think this is about a library that contains logging calls
(eg: multiprocessing), and is used in j-random-application, and while
prototyping/debugging the application you want to access that logging
information without having to write a logging infrastructure into your
app first.  Or you want to access it while debugging someone _else_'s
application...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:02:37 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 21 Sep 2009 21:02:37 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253566957.11.0.0207988326745.issue6958@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

How about putting this into the logging module instead?  Instead of
"python <logging options> <program> <program options>", making it
"python -m logging <logging options> <program> <program options".

This:

  * involves no changes to the core interpreter
  * only requires Python to be written, not C
  * Lets other VMs benefit from the feature immediately
  * Follows what seems to be the emerging convention for this kind of
(eg pdb, unittest)
  * Still allows logging to be configured for arbitrary programs that
wouldn't otherwise be configurable in this way

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:10:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:10:58 +0000
Subject: [issue6348] solaris/aix: Py_Initialize: can't initialize sys standard
	streams
In-Reply-To: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>
Message-ID: <1253567458.54.0.784798262574.issue6348@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> os.popen causes illegal seek on AIX in Python 3.1rc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6348>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:15:28 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Sep 2009 21:15:28 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1253567728.88.0.789446717014.issue6236@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:18:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:18:24 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1253567904.19.0.793033256014.issue6236@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:19:01 2009
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 21 Sep 2009 21:19:01 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253567941.62.0.584466965379.issue6958@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

How do these "global" settings (either via the interpreter or a wrapper
in the logging module) change what an app might do on its own?  IOW, if
my app is already written to configure logging, and someone invokes it
with these other settings, which settings are used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:34:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:34:12 +0000
Subject: [issue6960] test_telnetlib gives spurious output
In-Reply-To: <1253568852.27.0.259606507401.issue6960@psf.upfronthosting.co.za>
Message-ID: <1253568852.27.0.259606507401.issue6960@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I just got the following traceback:

Exception in thread Thread-538:
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/threading.py", line 509, in
_bootstrap_inner
    self.run()
  File "/home/antoine/py3k/__svn__/Lib/threading.py", line 462, in run
    self._target(*self._args, **self._kwargs)
  File "/home/antoine/py3k/__svn__/Lib/test/test_telnetlib.py", line 25,
in server
    conn, addr = serv.accept()
  File "/home/antoine/py3k/__svn__/Lib/socket.py", line 120, in accept
    fd, addr = self._accept()
socket.error: [Errno 4] Interrupted system call


Interestingly, it happens *after* test_telnetlib returned successfully.

----------
components: Tests
messages: 92962
nosy: jackdied, pitrou
priority: normal
severity: normal
status: open
title: test_telnetlib gives spurious output
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6960>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:36:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:36:18 +0000
Subject: [issue6961] test_distutils failure
In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
Message-ID: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following (deterministic) failure on the py3k branch:

test_distutils
0 blocks
find:
`/home/antoine/tmp/tmpX6PtRb/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/tmpNJkuVH/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 test_distutils failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_util.py",
line 145, in test_get_platform
    self.assertEquals(get_platform(), 'macosx-10.4-universal')
AssertionError: 'macosx-10.4-intel' != 'macosx-10.4-universal'

1 test failed:
    test_distutils

----------
assignee: tarek
components: Distutils, Tests
messages: 92963
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6961>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:43:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:43:39 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1253569419.73.0.57204859319.issue6236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch! Committed in r75007, r75008, r75009, r75010.
If there's any problem, please reopen.

----------
resolution: accepted -> fixed
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Mon Sep 21 23:46:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:46:01 +0000
Subject: [issue6961] test_distutils failure
In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
Message-ID: <1253569561.35.0.415560389872.issue6961@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It also fails on release31-maint, but not on trunk.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6961>
_______________________________________

From report at bugs.python.org  Tue Sep 22 00:26:52 2009
From: report at bugs.python.org (thewtex)
Date: Mon, 21 Sep 2009 22:26:52 +0000
Subject: [issue6962] traceback.format_exception_only does not return
	SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>


New submission from thewtex <matt at mmmccormick.com>:

On Python 2.6.2, and possibly other versions, in the traceback module,
format_exception_only does not behave correctly when printout out a
SyntaxError.  An extra newline is inserted before the carot.  E.g.

 38         exceptionType, exceptionValue, exceptionTraceback =
sys.exc_info()                        
 39         sys.stderr.write("Exception:\n")
 40         ex = traceback.format_exception_only(exceptionType,
exceptionValue)
 41         sys.stderr.write(repr(ex))
 42         for line in ex:
 43             sys.stderr.write(line) 

yields, e.g.
Exception:
['  File "/home/matt/apps/posac/source/posac/posac_main.py", line 12\n',
'    def run()\n', '            \n^\n', 'SyntaxError: invalid syntax\n']
 File "/home/matt/apps/posac/source/posac/posac_main.py", line 12
    def run()
            
^
SyntaxError: invalid syntax

When it should be:
Exception:
['  File "/home/matt/apps/posac/source/posac/posac_main.py", line 12\n',
'    def run()\n', '             ^\n', 'SyntaxError: invalid syntax\n']
 File "/home/matt/apps/posac/source/posac/posac_main.py", line 12
    def run()
             ^
SyntaxError: invalid syntax


Attached is a patch.  This patch has been tested on gentoo linux.

----------
messages: 92966
nosy: thewtex
severity: normal
status: open
title: traceback.format_exception_only does not return SyntaxError carot correctly
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6962>
_______________________________________

From report at bugs.python.org  Tue Sep 22 00:27:12 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 21 Sep 2009 22:27:12 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253572032.32.0.374552539178.issue1766304@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

Thanks for your feedback. I added a few tests and changed the bits you
criticized.

----------
Added file: http://bugs.python.org/file14945/range.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Tue Sep 22 01:49:46 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 21 Sep 2009 23:49:46 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253576986.75.0.475361844451.issue6877@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Is this open or closed? Wondering as I just updated my checkout and I am 
now segfaulting at the command-line whenever I import something under 
readline 6.0 which was working fine.


>>> import tokenize

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001003effa6 in call_readline (sys_stdin=0x7fff70a230c0, 
sys_stdout=0x7fff70a23158, prompt=0x1005da194 ">>> ") at readline.c:1029
1029					line = history_get(state->length 
- 1)->line;
(gdb) bt
#0  0x00000001003effa6 in call_readline (sys_stdin=0x7fff70a230c0, 
sys_stdout=0x7fff70a23158, prompt=0x1005da194 ">>> ") at readline.c:1029
#1  0x00000001000044d8 in PyOS_Readline (sys_stdin=0x7fff70a230c0, 
sys_stdout=0x7fff70a23158, prompt=0x1005da194 ">>> ") at 
myreadline.c:208
#2  0x0000000100006ce0 in tok_nextc (tok=0x100890c10) at tokenizer.c:781
#3  0x0000000100005464 in tok_get (tok=0x100890c10, 
p_start=0x7fff5fbfe9e8, p_end=0x7fff5fbfe9e0) at tokenizer.c:1128
#4  0x00000001000053a4 in PyTokenizer_Get (tok=0x100890c10, 
p_start=0x7fff5fbfe9e8, p_end=0x7fff5fbfe9e0) at tokenizer.c:1568
#5  0x000000010000388b in parsetok (tok=0x100890c10, g=0x100251f68, 
start=256, err_ret=0x7fff5fbfeb10, flags=0x7fff5fbfeb0c) at 
parsetok.c:159
#6  0x0000000100003fe8 in PyParser_ParseFileFlagsEx (fp=0x7fff70a230c0, 
filename=0x1001fba28 "<stdin>", g=0x100251f68, start=256, 
ps1=0x1005da194 ">>> ", ps2=0x1005da2b4 "... ", err_ret=0x7fff5fbfeb10, 
flags=0x7fff5fbfeb0c) at parsetok.c:106
#7  0x0000000100193b76 in PyParser_ASTFromFile (fp=0x7fff70a230c0, 
filename=0x1001fba28 "<stdin>", start=256, ps1=0x1005da194 ">>> ", 
ps2=0x1005da2b4 "... ", flags=0x7fff5fbfeea0, errcode=0x7fff5fbfebec, 
arena=0x1004427d0) at pythonrun.c:1461
#8  0x00000001001937c9 in PyRun_InteractiveOneFlags (fp=0x7fff70a230c0, 
filename=0x1001fba28 "<stdin>", flags=0x7fff5fbfeea0) at pythonrun.c:823
#9  0x0000000100193091 in PyRun_InteractiveLoopFlags (fp=0x7fff70a230c0, 
filename=0x1001fba28 "<stdin>", flags=0x7fff5fbfeea0) at pythonrun.c:763
#10 0x0000000100192db8 in PyRun_AnyFileExFlags (fp=0x7fff70a230c0, 
filename=0x1001fba28 "<stdin>", closeit=0, flags=0x7fff5fbfeea0) at 
pythonrun.c:732
#11 0x00000001001af808 in Py_Main (argc=1, argv=0x7fff5fbfef40) at 
main.c:603
#12 0x0000000100001325 in main (argc=1, argv=0x7fff5fbfef40) at 
python.c:23

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 02:34:36 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Sep 2009 00:34:36 +0000
Subject: [issue6823] time.strftime does unnecessary range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1253579676.87.0.98772726129.issue6823@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

time.strftime() now normalizes tm_isdst.

2.7: r75011
3.2: r75012

This could probably be backported to 2.6/3.1, but since this is purely a 
convenience thing and it is a (very) minor change in semantics I am not 
going to bother.

Thanks, Robert, for the initial patch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6823>
_______________________________________

From report at bugs.python.org  Tue Sep 22 04:03:09 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Tue, 22 Sep 2009 02:03:09 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1253584989.75.0.191447336537.issue6845@psf.upfronthosting.co.za>


Changes by Alejandro Santos <alejolp at alejolp.com>:


----------
nosy: +alejolp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Sep 22 04:20:38 2009
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 22 Sep 2009 02:20:38 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1253586038.71.0.619383189355.issue6845@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I like this. I'd love to see a test of this, though.

Pablo, do you think you could came up with a test? Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Sep 22 04:24:52 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Sep 2009 02:24:52 +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: <1253586292.62.0.631429939821.issue6105@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Tue Sep 22 04:28:32 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 22 Sep 2009 02:28:32 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>


New submission from Charles Cazabon <charlesc-python at pyropus.ca>:

Worker processes with multiprocessing.Pool live for the duration of the
Pool.  If the tasks they run happen to leak memory (from a C extension
module, or from creating cycles of unreachable objects, etc) or open
files or other resources, there's no easy way to clean them up.

Similarly, if one task passed to the pool allocates a large amount of
memory, but further tasks are small, that additional memory isn't
returned to the system because the process involved hasn't exited.

A common approach to this problem (as used by Apache, mod_wsgi, and
various other software) is to allow worker processes to exit (and be
replaced with fresh processes) after completing a specified amount of
work.  The attached patch (against Python 2.6.2, but applies to various
other versions with some fuzz) implements this as optional new behaviour
in multiprocessing.Pool().  An additional optional argument is specified
for the maximum number of tasks a worker process performs before it
exits and is replaced with a fresh worker process.

----------
components: Library (Lib)
files: worker-lifetime-python2.6.2.patch
keywords: patch
messages: 92971
nosy: charlesc
severity: normal
status: open
title: Add worker process lifetime to multiprocessing.Pool - patch included
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14946/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Sep 22 04:32:35 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 22 Sep 2009 02:32:35 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253586755.28.0.0258990559731.issue6963@psf.upfronthosting.co.za>


Changes by Charles Cazabon <charlesc-python at pyropus.ca>:


Removed file: http://bugs.python.org/file14946/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Sep 22 04:33:03 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 22 Sep 2009 02:33:03 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253586783.95.0.745602787994.issue6963@psf.upfronthosting.co.za>


Changes by Charles Cazabon <charlesc-python at pyropus.ca>:


Added file: http://bugs.python.org/file14947/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Sep 22 05:41:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Sep 2009 03:41:59 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253590919.4.0.69426817573.issue6963@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/issue6963>
_______________________________________

From report at bugs.python.org  Tue Sep 22 07:58:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 05:58:58 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253599138.34.0.498903386837.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should have been closed, although readline shouldn't crash either.

Brett: What version of OSX do you use? Readline works fine for me on OSX 
10.6 without GNU readline.

BTW. The crashlog indicates you are no longer using GNU readline, but 
use system readline instead (that is the libedit emulation layer). 

This is one thing we completely failed to look at: how to determine 
which one to use? We currently use the first readline we find, which 
will we the system one on OSX 10.5 or later. 

It may be better to either add a configure flag to explicitly select 
which one is preferential, or use the GNU version when it is found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 08:04:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 06:04:16 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253599456.03.0.395380324043.issue6957@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

It should be possible to tweak distutils to do the right thing for 
upcoming releases, distutils already contains some special code to allow 
building extensions for a univeral build on 10.3.9 (where the compiler 
doesn't support universal builds at all) and we could extend that for 
the compiler version on SL.

Implementation sketch:
* Record the compiler version during build (using configure)
* Store the compiler version as a variable in Makefile.pre.in
* Teach distutils to read that variable and adjust the compiler 
  path ($CC,$LD,...)

This bit would only be active on OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Tue Sep 22 11:16:48 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 22 Sep 2009 09:16:48 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>


New submission from Rene Dudfield <illume at users.sourceforge.net>:

python3.1

>>> import new
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named new

2to3-3.1 doesn't mention how to change it.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 92974
nosy: illume
severity: normal
status: open
title: import new fails
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Tue Sep 22 11:21:58 2009
From: report at bugs.python.org (djc)
Date: Tue, 22 Sep 2009 09:21:58 +0000
Subject: [issue6965] tmpnam should not be used if tempfile or mkstemp are
	available
In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
Message-ID: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

I have a bug report in the Gentoo tracker
(http://bugs.gentoo.org/show_bug.cgi?id=221183):

"This is a rather strange request, but please bear me.
While building Posix module, python checks (among others) for
tmpfile, tmpnam and tmpnam_r
however man pages state explicitly, that in case tmpfile is available, other
two should not be used
if libpython2.5.a is built with either of them, linker complains each
time it's
added

While this doesn't break anything, it's still a bit annoying.
so I propose to remove functionality as an enhancement:
to change in Modules/posixmodule.c
#ifdef HAVE_TMPNAM
to
#ifdef HAVE_TMPNAM && !defined(HAVE_TMPFILE)

Your thoughts?"

man 3 tmpnam state "Never use this function.  Use mkstemp(3) or
tmpfile(3) instead.".

Not sure whether this is exposed anywhere, but I figured this bug would
be better handled upstream from Gentoo.

----------
components: Extension Modules
messages: 92975
nosy: djc
severity: normal
status: open
title: tmpnam should not be used if tempfile or mkstemp are available
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6965>
_______________________________________

From report at bugs.python.org  Tue Sep 22 11:24:07 2009
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Tue, 22 Sep 2009 09:24:07 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253611447.43.0.225524512917.issue6964@psf.upfronthosting.co.za>


Quentin Gallet-Gilles <qgallet at gmail.com> added the comment:

The 'new' module has been removed in python 3.0. The documentation
advices you to use the 'types' modules instead
(http://docs.python.org/library/new.html).

I'm also pretty sure you get a message for this module if you enable the
warnings at interpreter startup in python 2.6.

----------
nosy: +quentin.gallet-gilles

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Tue Sep 22 11:28:08 2009
From: report at bugs.python.org (Johan Tufvesson)
Date: Tue, 22 Sep 2009 09:28:08 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>


New submission from Johan Tufvesson <jot at hms.se>:

In the unittest module, TestCase class:

If one wants to provide a more descriptive fail message compared to the
default, it is often valuable to be able to refer to the arguments
evaluated by the fail*- (or assert*-) method. This can be accomplished
by binding names to the evaluated values before the call to the
fail*-methods, and then providing a string with the values embedded as
needed. This, however, can be quite cumbersome when there are a lot of
calls to fail*-methods.

Today:
Arg1 = RealValue()
Arg2 = ExpectedValue()
self.failUnlessEqual(Arg1, Arg2, "Got {0}, but expected
{1}.".format(Arg1, Arg2))

Proposed solution:
In the fail*-methods, check if the msg argument is some kind of string
(basestring?), and run the format() method on the string with the
supplied arguments. This would result in code like this:

self.failUnlessEqual(RealValue(), ExpectedValue(), "Got {0}, but
expected {1}.")

----------
components: Library (Lib)
messages: 92977
nosy: tuben
severity: normal
status: open
title: Ability to refer to arguments in TestCase.fail* methods
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________

From report at bugs.python.org  Tue Sep 22 12:11:20 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 22 Sep 2009 10:11:20 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253614280.67.0.650334389738.issue6964@psf.upfronthosting.co.za>


Rene Dudfield <illume at users.sourceforge.net> added the comment:

Hi,

yes it does report a warning with 2.6, thanks.

python2.6 -3 -c "import new"
-c:1: DeprecationWarning: The 'new' module has been removed in Python
3.0; use the 'types' module instead.

I guess it should be a TODO item with 2to3.

cheers,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Tue Sep 22 12:15:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 22 Sep 2009 10:15:04 +0000
Subject: [issue6961] test_distutils failure
In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
Message-ID: <1253614504.96.0.588027481681.issue6961@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That was fixed already in trunk, and a pending merging waiting to be
merged. I've just merged in r75013 and r75014

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6961>
_______________________________________

From report at bugs.python.org  Tue Sep 22 12:17:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 22 Sep 2009 10:17:37 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253614657.37.0.898317613652.issue6964@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Tue Sep 22 12:21:23 2009
From: report at bugs.python.org (Sascha)
Date: Tue, 22 Sep 2009 10:21:23 +0000
Subject: [issue6967] codec windows1256 should be windows windows-1256
In-Reply-To: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za>
Message-ID: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za>


New submission from Sascha <python-bugreport at discorner.de>:

It seem that there's a dash missing.

http://docs.python.org/dev/library/codecs.html#standard-encodings

>>> u'Sorry, this in here makes no sense'.encode('windows1256')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
LookupError: unknown encoding: windows1256

On the other hand windows-1256 works.

----------
assignee: georg.brandl
components: Documentation
files: codecs.rst.patch
keywords: patch
messages: 92980
nosy: DerSascha, georg.brandl
severity: normal
status: open
title: codec windows1256 should be windows windows-1256
versions: Python 2.5, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14948/codecs.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6967>
_______________________________________

From report at bugs.python.org  Tue Sep 22 12:48:56 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 10:48:56 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1253616536.4.0.145439176425.issue6834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached file 'pythonw.c' is a first version of a better pythonw 
executable.

This version uses posix_spawn rather than execv to start the real 
interpreter. The main advantage of the new implementation is that 'arch 
-ppc pythonw' works as expected, with the current version of pythonw the 
'arch' command only affects the pythonw executable and not the real 
interpreter.

Todo:
* I'm not use if the '-X32bit' option is a good idea or not.

  The basic idea of this is to provide an easy way to force python to 
  start in 32bit mode (for use in #! lines) for scripts that need it
  (basicly anything that needs to access Carbon GUI APIs, including most
  current Python GUI libraries)

* The implementation of '-X32bit' is sucky, it contains a copy of the
  getopt format string from Py_Main in Modules/main.c

* The path to the real executable is hardcoded for a standard framework
  install of 2.7 (easily changed to the same mechanism as used by
  the current edition of pythonw)

  What I'd like to do is link pythonw to the framework and use dyld
  introspection to deduce the path to the real executable. That's 
  slightly more complicated, but would provide a clean way to reuse
  the executable in tools like virtualenv without recompiling.

----------
Added file: http://bugs.python.org/file14949/pythonw.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Tue Sep 22 12:55:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 22 Sep 2009 10:55:29 +0000
Subject: [issue6967] codec windows1256 should be windows windows-1256
In-Reply-To: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za>
Message-ID: <1253616929.54.0.264413104495.issue6967@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r75015.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6967>
_______________________________________

From report at bugs.python.org  Tue Sep 22 13:07:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 22 Sep 2009 11:07:13 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1253617633.39.0.111967646381.issue6966@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/issue6966>
_______________________________________

From report at bugs.python.org  Tue Sep 22 13:12:01 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 22 Sep 2009 11:12:01 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1253617921.02.0.941023586397.issue6966@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The new longMessage class attribute on TestCase already shows both
arguments when a call to assertEqual fails (the failUnless methods are
now deprecated) - even if you supply a custom message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________

From report at bugs.python.org  Tue Sep 22 13:35:44 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Sep 2009 11:35:44 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <4A7BE9BE.1010601@egenix.com>
Message-ID: <4AB7DD06.2040800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> int()/float() use the decimal codec for numbers - this only supports
> base-10 numbers. For hex numbers, we'd need a new hex codec (only
> the encoder part, actually), otherwise, int('a') would start to return
> 10.

That's not true. PyUnicode_EncodeDecimal could happily accept hexdigits,
and int(u'a') would still be rejected. In fact, PyUnicode_EncodeDecimal
*already* accepts arbitrary Latin-1 characters, whether they represent
digits or not. I suppose this is to support non-decimal bases, so it
would only be consequential to widen this to all characters that
reasonably have the Hex_Digit property (although I'm unsure which ones
are excluded at the moment).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Tue Sep 22 13:58:24 2009
From: report at bugs.python.org (Johan Tufvesson)
Date: Tue, 22 Sep 2009 11:58:24 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1253620704.91.0.769794787605.issue6966@psf.upfronthosting.co.za>


Johan Tufvesson <jot at hms.se> added the comment:

I admit that I had not seen the longMessage attribute. That is better
than the present possibilities in 2.6, although not as configurable as
my suggestion (but with better backwards compatibility).

Personally I will be a user of the longMessage feature, dreaming of even
more functionality.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________

From report at bugs.python.org  Tue Sep 22 14:32:57 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 22 Sep 2009 12:32:57 +0000
Subject: [issue6968] numpy extensions to distutils... are a source of
	improvements for distutils
In-Reply-To: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za>
Message-ID: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za>


New submission from Rene Dudfield <illume at users.sourceforge.net>:

Hi,

numpy includes a numpy/distutils package which has a lot of
goodies/fixes which might be able to be incorporated into the main
distutils.

Adding this note so distutils maintainers are aware of it.

cheers,

----------
assignee: tarek
components: Distutils
messages: 92986
nosy: illume, tarek
severity: normal
status: open
title: numpy extensions to distutils... are a source of improvements for distutils
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6968>
_______________________________________

From report at bugs.python.org  Tue Sep 22 14:35:03 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 22 Sep 2009 12:35:03 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253622903.49.0.509725856863.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Hi Charles; I don't see a doc update for this (see multiprocessing.rst) or 
unit tests. I'm not against it, but before I can commit this, I'll need 
those things

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Sep 22 14:56:13 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Tue, 22 Sep 2009 12:56:13 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253624173.35.0.307617375792.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Brett,

what does this command return for you?

otool -L /path/to/lib/python2.4/lib-dynload/readline.so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:08:18 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Tue, 22 Sep 2009 13:08:18 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253624898.77.0.631992629414.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Make that python2.6 in the command above.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:13:47 2009
From: report at bugs.python.org (nestor)
Date: Tue, 22 Sep 2009 13:13:47 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1253625227.97.0.447066248105.issue6236@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

Fantastic. Applied the patch and it solved the problem with xlc 8.0 on
AIX 5.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:17:15 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 13:17:15 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253625435.49.0.105799711417.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Better yet:

   otool -vL $(python -c 'import readline; print readline.__file__')

(Replace "python" by the interpreter that your actually using).

I'm still interested to know the OS release as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:24:34 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 22 Sep 2009 13:24:34 +0000
Subject: [issue6968] numpy extensions to distutils... are a source of
	improvements for distutils
In-Reply-To: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za>
Message-ID: <1253625874.35.0.779017901927.issue6968@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the note Rene,

Maybe someone from Numpy could help on this, by adding one issue per
feature/change proposal, and if possible with a patch including the
change with a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6968>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:45:11 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Tue, 22 Sep 2009 13:45:11 +0000
Subject: [issue6969] configparser
In-Reply-To: <1253627111.3.0.369651461039.issue6969@psf.upfronthosting.co.za>
Message-ID: <1253627111.3.0.369651461039.issue6969@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello! Seems configparser is broken in recent versions of py3k. Please also check older 
versions of python.

$ python3 ./cfgexample.py 
Traceback (most recent call last):
  File "./cfgexample.py", line 9, in <module>
    config.write(configfile)
  File "/usr/local/py3k/lib/python3.2/configparser.py", line 394, in write
    fp.write("[%s]\n" % section)
TypeError: must be bytes or buffer, not str
$ cat ./cfgexample.py 
import configparser

config = configparser.RawConfigParser()

config.add_section('Section1')
config.set('Section1', 'int', '15')

with open('example.cfg', 'wb') as configfile:
    config.write(configfile)
$ python3 --version
Python 3.2a0


I've built this version of python:
$ hg head
changeset:   4765:488e143fad23
branch:      py3k
tag:         tip
user:        tarek.ziade
date:        Tue Sep 22 12:08:13 2009 +0200
summary:     [svn r75013] Merged revisions 74812 via svnmerge from

----------
components: Library (Lib)
messages: 92993
nosy: exe
severity: normal
status: open
title: configparser
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6969>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:51:00 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 22 Sep 2009 13:51:00 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253627460.5.0.200058818902.issue6958@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Both Doug and Jean-Paul have made good points, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Tue Sep 22 15:54:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 22 Sep 2009 13:54:03 +0000
Subject: [issue6969] configparser
In-Reply-To: <1253627111.3.0.369651461039.issue6969@psf.upfronthosting.co.za>
Message-ID: <1253627643.71.0.15691403343.issue6969@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It seems that nobody updated the documentation to say that configparser
operates on text files.  The example is also wrong, it should open the
file in 'w' mode, not 'wb'.

Fixed in r75016.

PS: please use more expressive titles for issues in the future.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6969>
_______________________________________

From report at bugs.python.org  Tue Sep 22 16:07:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 14:07:45 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253628465.92.0.306277195251.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've tested with readline 6 on OSX 10.6 as well. Both that and the system 
readline (libedit emulation) work just fine for me.

The current behaviour for me:
* When GNU readline is present in /usr/local it gets used
* Otherwise libedit gets used

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 16:27:40 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 14:27:40 +0000
Subject: [issue6959] OS X 10.6 / Snow Leopard: building 2.6 maintenance
	release fails for some modules (architecture issue)
In-Reply-To: <1253558979.67.0.56410771712.issue6959@psf.upfronthosting.co.za>
Message-ID: <1253629660.58.0.34692157795.issue6959@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As Ned noticed the readline failure is expected unless you have installed 
GNU readline in /usr/local. The system readline is not supported in the 
2.6 branch, it will be supported in 2.7 (at least on Snow Leopard)

I've commited a fix for the Nav.c errors in r75017 (trunk) and r75018 
(2.6)

In both cases the fix disabled Carbon.Nav in 64-bit mode because basicly 
all of the functions in that module wrap deprecated code.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6959>
_______________________________________

From report at bugs.python.org  Tue Sep 22 17:23:18 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Tue, 22 Sep 2009 15:23:18 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253632998.18.0.920050323925.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

I assume you had to pass extra -I and -L flags when compiling with GNU 
readline.  Right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 17:36:18 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 22 Sep 2009 15:36:18 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253633778.61.0.347123152316.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Alright, I'll add those.  Thanks for looking at it; first pass was
mostly to ensure it wouldn't be wasted work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Sep 22 17:37:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Sep 2009 15:37:06 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's some strange behaviour in py3k:

newton:py3k dickinsm$ ./python.exe
Python 3.2a0 (py3k:75015, Sep 22 2009, 16:25:12) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     def __eq__(self, other):
...         print("In A.__eq__", self, other)
...         return NotImplemented
... 
>>> class B:
...     def __eq__(self, other):
...         print("In B.__eq__", self, other)
...         return NotImplemented
... 
>>> A() == B()
In A.__eq__ <__main__.A object at 0x34d030> <__main__.B object at 0x448210>
In B.__eq__ <__main__.B object at 0x448210> <__main__.A object at 0x34d030>
In B.__eq__ <__main__.B object at 0x448210> <__main__.A object at 0x34d030>
In A.__eq__ <__main__.A object at 0x34d030> <__main__.B object at 0x448210>
False

I'd expect to see only one call to A.__eq__ and one call to B.__eq__.

The cause seems to be that:

 - slot_tp_richcompare (in typeobject.c) makes two calls to half_richcompare,
   one with the original arguments and one with reverse arguments, *and*

 - do_richcompare (in object.c) also makes two calls to the tp_richcompare
   slot; again, one with the original arguments and one with the reversed
   arguments.

I tried removing the second block of slot_tp_richcompare (still in py3k);  
make and make test succeeded without any problems.  Removing this block does 
change behaviour though, so probably should not happen until 3.2, given that 
no-one appears to have reported the current behaviour actually causing any 
problems.

The duplicate calls also exist in 2.x;  figuring out a solution there (and 
being sure that the solution does the right thing) looks complicated, thanks 
to all the rich-compare/three-way-compare interactions.

----------
components: Interpreter Core
messages: 93000
nosy: mark.dickinson
severity: normal
stage: needs patch
status: open
title: Redundant calls made to comparison methods.
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________

From report at bugs.python.org  Tue Sep 22 17:38:26 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 15:38:26 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253633906.46.0.576251053399.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Zvezdan: I did not have to pass additional arguments to get readline, the 
default machinery automaticly picks up libraries in /usr/local.

I'd love to have a way to restrict the default compiler and linker search 
paths to system locations (e.g. exclude /usr/local and 
/Library/Frameworks), but that's sadly enough not easily possible (and the 
issue is in the compiler not distutils)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 17:57:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Sep 2009 15:57:28 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1253635048.25.0.502972680922.issue6970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And here's an example from trunk:

Python 2.7a0 (trunk:75012M, Sep 22 2009, 11:16:39) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
...     def __eq__(self, other):
...         print "A.__eq({!r}, {!r})".format(self, other)
...         return NotImplemented
... 
>>> A() == A()
A.__eq(<__main__.A object at 0x39f670>, <__main__.A object at 0x39f610>)
A.__eq(<__main__.A object at 0x39f610>, <__main__.A object at 0x39f670>)
A.__eq(<__main__.A object at 0x39f670>, <__main__.A object at 0x39f610>)
A.__eq(<__main__.A object at 0x39f610>, <__main__.A object at 0x39f670>)
A.__eq(<__main__.A object at 0x39f610>, <__main__.A object at 0x39f670>)
A.__eq(<__main__.A object at 0x39f670>, <__main__.A object at 0x39f610>)
False

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________

From report at bugs.python.org  Tue Sep 22 18:33:31 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 22 Sep 2009 16:33:31 +0000
Subject: [issue6269] threading documentation makes no mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1253637211.96.0.818663667527.issue6269@psf.upfronthosting.co.za>


Rene Dudfield <illume at users.sourceforge.net> added the comment:

hello,

CPU intensive programs can also benefit from the GIL if they use code
which releases the GIL around the CPU intensive parts.

Some parts of python do this, as do the numpy and pygame extensions
amongst others.

Another good, but separate, documentation patch would be to document
which functions release the GIL.


cheers,

----------
nosy: +illume

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Tue Sep 22 18:53:08 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 22 Sep 2009 16:53:08 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <4AB7DD06.2040800@v.loewis.de>
Message-ID: <4AB90123.7050500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> int()/float() use the decimal codec for numbers - this only supports
>> base-10 numbers. For hex numbers, we'd need a new hex codec (only
>> the encoder part, actually), otherwise, int('a') would start to return
>> 10.
> 
> That's not true. PyUnicode_EncodeDecimal could happily accept hexdigits,
> and int(u'a') would still be rejected. In fact, PyUnicode_EncodeDecimal
> *already* accepts arbitrary Latin-1 characters, whether they represent
> digits or not. I suppose this is to support non-decimal bases, so it
> would only be consequential to widen this to all characters that
> reasonably have the Hex_Digit property (although I'm unsure which ones
> are excluded at the moment).

The codec currently doesn't look at the base at all - and shouldn't
need to:

It simply converts input characters that have a decimal digit value
associated with them, to the usual ASCII digits in preparation
for parsing them using the standard number parsing tools we have in
Python.

This is to support number representations using non-ASCII code
points for digits (e.g. Japanese or Sanskrit numbers)

http://sp.cis.iwate-u.ac.jp/sp/lessonj/doc/numbers.html
http://veda.wikidot.com/sanskrit-numbers

All other Latin-1 characters are passed through as-is, so you
can already use the codec to e.g. prepare parsing of hex
values.

Also note that we already have a hex codec in Python 2.x
which converts between the hex representations of a string
and its regular form. This was removed in 3.x for some reason
I don't understand (probably just an oversight).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Tue Sep 22 19:50:12 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 22 Sep 2009 17:50:12 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253641812.46.0.109026223787.issue6957@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Tweaking distutils as you propose sounds like a good idea to help with 
future releases.  Also, the proposed installer variant to support 64-bit 
would not have this problem as it would only work with 10.5 and above.  
(Perhaps there's a warning in all this that trying to support too many 
releases with one installer is not a good thing.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Tue Sep 22 20:54:06 2009
From: report at bugs.python.org (cscscs)
Date: Tue, 22 Sep 2009 18:54:06 +0000
Subject: [issue6959] OS X 10.6 / Snow Leopard: building 2.6 maintenance
	release fails for some modules (architecture issue)
In-Reply-To: <1253629660.58.0.34692157795.issue6959@psf.upfronthosting.co.za>
Message-ID: <4AB91D4C.8000102@schleiermachers.de>


cscscs <chris at schleiermachers.de> added the comment:

hi ron,
thanks for the information.
much appreciated.

best regards.

Ronald Oussoren wrote:
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> As Ned noticed the readline failure is expected unless you have installed 
> GNU readline in /usr/local. The system readline is not supported in the 
> 2.6 branch, it will be supported in 2.7 (at least on Snow Leopard)
>
> I've commited a fix for the Nav.c errors in r75017 (trunk) and r75018 
> (2.6)
>
> In both cases the fix disabled Carbon.Nav in 64-bit mode because basicly 
> all of the functions in that module wrap deprecated code.
>
> ----------
> resolution:  -> accepted
> stage:  -> committed/rejected
> status: open -> closed
> versions: +Python 2.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6959>
> _______________________________________
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6959>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:01:55 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 22 Sep 2009 19:01:55 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253566957.11.0.0207988326745.issue6958@psf.upfronthosting.co.za>
Message-ID: <4AB91F1D.4090100@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> Jean-Paul Calderone:
> 
> How about putting this into the logging module instead?  Instead of
> "python <logging options> <program> <program options>", making it
> "python -m logging <logging options> <program> <program options".
> 
> This:
> 
>   * involves no changes to the core interpreter
>   * only requires Python to be written, not C
>   * Lets other VMs benefit from the feature immediately
>   * Follows what seems to be the emerging convention for this kind of
> (eg pdb, unittest)
>   * Still allows logging to be configured for arbitrary programs that
> wouldn't otherwise be configurable in this way

This is a very good idea, and fully covers my use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:03:37 2009
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 22 Sep 2009 19:03:37 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253567941.62.0.584466965379.issue6958@psf.upfronthosting.co.za>
Message-ID: <4AB91F84.5040102@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> How do these "global" settings (either via the interpreter or a wrapper
> in the logging module) change what an app might do on its own?  IOW, if
> my app is already written to configure logging, and someone invokes it
> with these other settings, which settings are used?

IMO the same would happen as if logging.basicConfig() would have been called
followed by calls to the custom configuration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:10:46 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 19:10:46 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253646646.9.0.281396427397.issue6957@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There is a much easier solution for the 2.6.3 release: ensure that CC=gcc-
4.0 when building the installer.

That requires minimal changes to the build machinery and should be safe 
enough.

The only change to distutils I do want to make for 2.6.3 is to detect
compilation with an SDK that is not present and remove the -isysroot 
option in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:30:32 2009
From: report at bugs.python.org (Doug Hellmann)
Date: Tue, 22 Sep 2009 19:30:32 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253647832.9.0.972923158129.issue6958@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

@theller, I'm not sure what your point is.  I'm asking what the defined
behavior is if we provide some sort of global way to run a program with
logging configured, and then that app turns around and tries to
reconfigure it.  Should the last one to call the configuration
function(s) win, or the first?

I like the idea of adding this feature to the logging module better than
building it into the interpreter, but I still think it opens up areas
for unexpected behavior, and it would be better to just let each
application set up its own logging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:31:54 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Sep 2009 19:31:54 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253647914.58.0.152611528431.issue6957@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

r75022 (trunk) and r75023 (2.6) add the other half of my proposal: 
distutils will ignore -isysroot SDKPATH when SDKPATH is not present on the 
current system.

That combined with explicit compilation using gcc-4.0 should solve these 
build issues with the OSX binary installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:45:40 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 22 Sep 2009 19:45:40 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253648740.14.0.968096439142.issue6958@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@theller: Although your use case just covers using basicConfig, I can
just see users expecting the same mechanism to invoke configuration
stored in a logging configuration file, which is why I suggested the
config= variant. However, doughellmann raises the valid point of what
the semantics would be if the program you invoke via logging -m does its
own configuration.

With a simple implementation: If a script calls basicConfig after it has
been invoked with logging -m etc. then the basicConfig call won't do
anything, as if the root logger already has some handlers, the call is
essentially a no-op. If the called script loads a configuration file,
that will overwrite the configuration specified via logging -m.

Either way, it's not consistent IMO - sometimes the logging -m
configuration will seem to win, and other times, the called script's
configuration.

Of course, it could be argued that logging -m is intended for scripts
which don't do explicit configuration - I'm not sure of how strong an
argument this is.

Thinking caps on :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:46:45 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 22 Sep 2009 19:46:45 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253648805.67.0.804509222367.issue6958@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Ummm, s/logging -m/-m logging/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________

From report at bugs.python.org  Tue Sep 22 21:49:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Sep 2009 19:49:50 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253648990.29.0.934189332685.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Great---thanks!

Would it be worth using PyObject_IsTrue instead of comparing with zero 
using PyObject_RichCompareBool?  (Sorry;  should have spotted this last 
time around.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Tue Sep 22 22:30:06 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Sep 2009 20:30:06 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253651406.66.0.873543447698.issue6877@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm on OS X 10.6 and I *thought* I was using GNU Readline 6. But if my 
backtrace implies otherwise something must have gotten messed up somewhere 
on my end. When I deleted Readline and rebuilt everything worked fine.

I'm going to go ahead and close this as you got it build and working for 
yourself that's good enough for me, Ronald.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 22:33:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Sep 2009 20:33:53 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253651633.37.0.305783868719.issue6964@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Benjamin can re-open if he wants, but having 2to3 emit warnings about 
deprecated modules is not what it is meant to do. 2to3 is supposed to only 
be run once you are running against 2.6 w/ no DeprecationWarning or 
Py3KWarning being raised, which would have covered this issue.

If the docs don't make this clear then they need to be changed to do so 
(and that should be a new issue anyway).

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Tue Sep 22 22:37:18 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Sep 2009 20:37:18 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1253651838.4.0.660328907921.issue6970@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I say fix it in 3.2 and don't worry about 2.x unless you really want to. 
As you said, it's rather tricky to untangle all of that and no one has 
complained yet. Plus it is a semantic change.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________

From report at bugs.python.org  Tue Sep 22 23:02:00 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Tue, 22 Sep 2009 21:02:00 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1253653320.22.0.641905193113.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Brett,

IMO, your backtrace only implies that readline module was built 
believing it has libedit (i.e., include files were system ones from 
/usr/include).

However, the following scenario is possible.  Some packaging tools 
choose to divide library packages into a runtime part and a development 
part.  If you had a copy of readline that was a runtime part only, it 
would have /usr/local/lib/* files but not /usr/local/include/* files 
(development part would have them).

Because of the way setup.py stashes /usr/local/lib first in the path, 
the build could have used system /usr/include/* file and linked to your 
local copy of readline library.

This is just a wild guess of course.

That's why I was interested in the output of otool command on your build 
of readline module.  That would tell us what it was linked to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Sep 22 23:48:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Sep 2009 21:48:01 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253656081.96.0.507832962862.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Answering myself:  probably not worth it:  I failed to notice that you 
already need zero for the 'step > 0' comparison.

Applied in r75028.

Leaving open for consideration of 2.x xrange.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Tue Sep 22 23:50:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 22 Sep 2009 21:50:30 +0000
Subject: [issue6971] Add the SIO_KEEPALIVE_VALS option to socket.ioctl
In-Reply-To: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
Message-ID: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Adding the SIO_KEEPALIVE_VALS option to socket.ioctl on windows allows a 
windows user to specify the timeout and interval for TCP keepalive support 
differently from the defaults specified in RFC 1122 on a per-socket basis.  
The 'option' is a tuple corresponging to the 'struct tcp_keepalive' 
expected by WSAIoctl
See http://msdn.microsoft.com/en-us/library/dd877220(VS.85).aspx for 
details.

----------
components: IO
files: wsaioctl.patch
keywords: easy, patch, patch
messages: 93020
nosy: krisvale
severity: normal
status: open
title: Add the SIO_KEEPALIVE_VALS option to socket.ioctl
versions: Python 2.7
Added file: http://bugs.python.org/file14950/wsaioctl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6971>
_______________________________________

From report at bugs.python.org  Wed Sep 23 00:10:52 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 22 Sep 2009 22:10:52 +0000
Subject: [issue6972] zipfile.ZipFile
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

ZipFile.extractall happily overwrites any file on the filesystem. One
can put files with a name like "//etc/password" in a zip file and
extractall will overwrite /etc/password (with sufficient rights).

The docs say:

ZipFile.extractall([path[, members[, pwd]]])

    Extract all members from the archive to the current working
directory. path specifies a different directory to extract to. members
is optional and must be a subset of the list returned by namelist(). pwd
is the password used for encrypted files.


I read that as: it will put all files into path or a subdirectory.
Using names like "../../../etc/password" also leads to files being
written outside that path directory.

----------
components: Library (Lib)
messages: 93021
nosy: schmir
severity: normal
status: open
title: zipfile.ZipFile
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 23 00:11:34 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 22 Sep 2009 22:11:34 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1253657494.39.0.657699899485.issue6972@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
title: zipfile.ZipFile -> zipfile.ZipFile overwrites files outside destination path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 23 00:47:48 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Tue, 22 Sep 2009 22:47:48 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>


New submission from Milko Krachounov <python at milko.3mhz.net>:

When subprocess.Popen.send_signal is called, it simply calls
os.kill(self.pid, ...) without checking whether the child has already
terminated. If the child has been terminated, and Popen.wait() or
Popen.poll() have been called, a process with PID self.pid no longer
exists, and what's worse, could belong to a totally unrelated process.

A better behavior would be to raise an exception when self.returncode is
not None. Alternatively, self.pid might be set to None after the process
has been terminated, as it is no longer meaningful. Or to another value
that would be invalid pid and invalid argument to os.kill and os.wait,
but unlike None would still evaluate to True.

----------
components: Library (Lib)
messages: 93022
nosy: milko.krachounov
severity: normal
status: open
title: subprocess.Popen.send_signal doesn't check whether the process has terminated
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Wed Sep 23 01:58:28 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 22 Sep 2009 23:58:28 +0000
Subject: [issue6971] Add the SIO_KEEPALIVE_VALS option to socket.ioctl
In-Reply-To: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
Message-ID: <1253663908.99.0.364864886347.issue6971@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6971>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:31:59 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:31:59 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1253683919.22.0.317451769364.issue3786@psf.upfronthosting.co.za>


Ian Donaldson <iand at ekit-inc.com> added the comment:

For those not desiring the use of the chgat function and wishing
to avoid all the fun suggested in the last post (like me), and just
get a _cursesmodule built on Solaris 9 or 10... I enclose a simple patch.

----------
nosy: +iandekit
Added file: http://bugs.python.org/file14951/EKIT.PATCH1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:38:37 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:38:37 +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: <1253684317.44.0.401197772601.issue3876@psf.upfronthosting.co.za>


Ian Donaldson <iand at ekit-inc.com> added the comment:

Similarly, compile fails on Solaris 9 due to lack of sem_timedwait()
so here is a patch for that.  Solaris 10 was the first Solaris
to have this function so the patch adapts for that case.

----------
nosy: +iandekit
Added file: http://bugs.python.org/file14952/EKIT.PATCH3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3876>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:42:14 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:42:14 +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: <1253684534.83.0.60691172565.issue3876@psf.upfronthosting.co.za>


Ian Donaldson <iand at ekit-inc.com> added the comment:

Similar to aix-patch, I enclose what I did for compilation
on Solaris 9, using macros from Solaris 10's headers.

These differ slightly to the aix ones, but I don't know if the
difference matters.  (alignment related)

----------
Added file: http://bugs.python.org/file14953/EKIT.PATCH2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3876>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:47:07 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:47:07 +0000
Subject: [issue6974] test_posix getcwd test leaves tmp  dir
In-Reply-To: <1253684827.18.0.268921836633.issue6974@psf.upfronthosting.co.za>
Message-ID: <1253684827.18.0.268921836633.issue6974@psf.upfronthosting.co.za>


New submission from Ian Donaldson <iand at ekit-inc.com>:

whilst debugging the getcwd test on Solaris 9 I noticed that
the rmtree() failed, as on Solaris rmdir(2) returns EINVAL
if cwd is the named directory.

Fix is to reorder the rmtree and chdir, see attached patch.

----------
components: Tests
files: EKIT.PATCH4
messages: 93026
nosy: iandekit
severity: normal
status: open
title: test_posix getcwd test leaves tmp  dir
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14954/EKIT.PATCH4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6974>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:55:14 2009
From: report at bugs.python.org (Sylwester Warecki)
Date: Wed, 23 Sep 2009 05:55:14 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>


New submission from Sylwester Warecki <swarecki at cox.net>:

Hi

The behavior of os.realpath function on Linux is different from the one 
presented by the system. 
Although the path (pointing to the linked dir) is correct
and is recognized by os.path.exists once it is resolved
by the realpath() it does not exist - at the end of the 
resolved path you will see the additional parent directory name.
you will see
..... /two/two at the end of the path.

Below is the code that shows the issue.

def linkGen():
  import os
  print os.getcwd()
  test = "./test"
  os.system( "rm -rf " + test  )  
  #os.mkdir( test )
  os.makedirs( test + "/one" )
  os.makedirs( test + "/two" )
  os.symlink( "../two", test + "/two/this_dir" )
  os.symlink( "../two/this_dir/this_dir/this_dir/this_dir/", test + 
"/one/that_dir" )
  print test + "/one/that_dir", "EXISTS?",   
  print os.path.exists( test + "/one/that_dir" )
  print os.path.realpath( test + "/one/that_dir" ), "EXISTS?", 
  print os.path.exists( os.path.realpath( test + "/one/that_dir" ) )
  os.system( "ls -l " + test + "/one/that_dir" )
  # the line above will show that system can see the directory just fine

linkGen()

----------
components: Library (Lib)
messages: 93027
nosy: swarecki
severity: normal
status: open
title: symlinks incorrectly resolved on Linux
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:55:37 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:55:37 +0000
Subject: [issue6976] getcwd hangs and leaks mem on Solaris <= 9 in very long
	file name case
In-Reply-To: <1253685337.93.0.462290997823.issue6976@psf.upfronthosting.co.za>
Message-ID: <1253685337.93.0.462290997823.issue6976@psf.upfronthosting.co.za>


New submission from Ian Donaldson <iand at ekit-inc.com>:

test_posix hung on Solaris 9 ... traced to getcwd test hanging.

This in turn was traced to the very long filename case...
It seems posixmodule was modified (since py2.4.3 at least) 
to retry getcwd with a bigger buffer if ERANGE occurs.  

However on Solaris 9 its not documented that ERANGE also
occurs if getcwd(3) can't cope with the path length, even
if the buffer is big enough.  This causes posix_getcwd() to
loop malloc'ing a bigger buffer, forever.

I enclose a patch that limits the damage, to 1Mbyte at least.
(not sure if more recent Solaris 9 patches than we have
provide another solution)

On Solaris 10, there is no problem as the getcwd() is implemented
as a system call.

----------
components: Build
files: EKIT.PATCH5
messages: 93028
nosy: iandekit
severity: normal
status: open
title: getcwd hangs and leaks mem on Solaris <= 9 in very long file name case
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file14955/EKIT.PATCH5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6976>
_______________________________________

From report at bugs.python.org  Wed Sep 23 07:56:21 2009
From: report at bugs.python.org (Sylwester Warecki)
Date: Wed, 23 Sep 2009 05:56:21 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1253685381.72.0.792341220033.issue6975@psf.upfronthosting.co.za>


Sylwester Warecki <swarecki at cox.net> added the comment:

Hi
I meant of course 
os.path.realpath()
Sylwester

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Wed Sep 23 09:23:01 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 07:23:01 +0000
Subject: [issue5114] 2.5.4.3 and 2.6.2 / test_threading hangs
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1253690581.53.0.90167367219.issue5114@psf.upfronthosting.co.za>


Ian Donaldson <iand at ekit-inc.com> added the comment:

FWIW it hangs on Solaris 9 also (sparc + x86)

----------
nosy: +iandekit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Wed Sep 23 10:34:23 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 23 Sep 2009 08:34:23 +0000
Subject: [issue4833] Explicit directories for zipfiles
In-Reply-To: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>
Message-ID: <1253694863.9.0.0494966720988.issue4833@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

it looks like this is fixed in 2.6.2.

I'm attaching a zipfile which cannot be extracted in 2.6.1

Running
python -c 'import zipfile; zipfile.ZipFile("test.zip").extractall()'
in 2.6.2 however works. 
but you should not do that anyway because of issue 6972

----------
nosy: +schmir
Added file: http://bugs.python.org/file14956/test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4833>
_______________________________________

From report at bugs.python.org  Wed Sep 23 13:51:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 23 Sep 2009 11:51:25 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253706685.86.0.233903153424.issue6964@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bottom line: move over to the types module *before* running 2to3.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Wed Sep 23 14:08:13 2009
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Sep 2009 12:08:13 +0000
Subject: [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

the following
>>> getopt.getopt('--testing=dr'.split(), '', ['testing'])[0]

would raise 'option --testing must not have an argument'.

Documentation reads, however: "Long options which require an argument
should be followed by an equal sign ('=')." Which is equivalent to
"options that don't require an argument, should not be followed by the
equal sign". The fact that in my example argument is not required does
not mean that argument cannot be passed.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 93033
nosy: SilentGhost, georg.brandl
severity: normal
status: open
title: Getopt documentation ambiguity
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________

From report at bugs.python.org  Wed Sep 23 15:35:35 2009
From: report at bugs.python.org (Kees Bos)
Date: Wed, 23 Sep 2009 13:35:35 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>


New submission from Kees Bos <k.bos at zx.nl>:

compiler.parse("d[1] = 1") should have a single tuple as subs


>>> compiler.parse("d[1] = 1")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN',
[Const(1)])], Const(1))]))
>>> compiler.parse("d[1,] = 2")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN',
[Const(1)])], Const(2))]))
>>> compiler.parse("d[1,2] = 3")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1),
Const(2)])], Const(3))]))
>>> compiler.parse("d[(1,)] = 2")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN',
[Tuple([Const(1)])])], Const(2))]))

----------
components: Library (Lib)
files: compiler.transformer.patch
keywords: patch
messages: 93034
nosy: kees
severity: normal
status: open
title: compiler.transformer dict key bug d[1,] = 1
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14957/compiler.transformer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

From report at bugs.python.org  Wed Sep 23 15:59:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 23 Sep 2009 13:59:08 +0000
Subject: [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1253714348.13.0.372078401195.issue6977@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sorry, I don't understand what the issue is.  Long options with
arguments use 'testing=', those without use 'testing'.  Could you please
elaborate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:11:27 2009
From: report at bugs.python.org (Kees Bos)
Date: Wed, 23 Sep 2009 14:11:27 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1253715087.11.0.983190923732.issue6978@psf.upfronthosting.co.za>


Kees Bos <k.bos at zx.nl> added the comment:

I just see that my patch is not correct, since the following is
supported by the language:

O[1:2:3, 4:5:6]

Where O[1:2:3, 4:5:6] == O[slice(1,2,3), slice(4,5,6)] ==
O.__getitem__((slice(1,2,3), slice(4,5,6)))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:24:24 2009
From: report at bugs.python.org (Kees Bos)
Date: Wed, 23 Sep 2009 14:24:24 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1253715864.0.0.510667322317.issue6978@psf.upfronthosting.co.za>


Kees Bos <k.bos at zx.nl> added the comment:

patch which honors O[1:2:3, 4:5:6]

----------
Added file: http://bugs.python.org/file14958/compiler.transformer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:24:54 2009
From: report at bugs.python.org (Kees Bos)
Date: Wed, 23 Sep 2009 14:24:54 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1253715894.63.0.793627317346.issue6978@psf.upfronthosting.co.za>


Changes by Kees Bos <k.bos at zx.nl>:


Removed file: http://bugs.python.org/file14957/compiler.transformer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:30:42 2009
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Sep 2009 14:30:42 +0000
Subject: [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1253716242.58.0.721807050187.issue6977@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

issue is in the wording: "Long options which require an argument
should be followed by an equal sign ('=')." What if the argument is
optional? Then by definition it is not required, but as my example shows
omitting the equal sign, would produce the error. 

I'd suggest that the docs should read something along these lines: "Long
options which accept an argument should be followed by an equal sign
('='). Passing an argument to an option without an equal sign is illegal."

Basically, it's not clear that "optional" arguments should be passed
like this:
>>> getopt.getopt('--testing='.split(), '', ['testing'])
Note the difference with my previous example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:36:27 2009
From: report at bugs.python.org (Doug Hellmann)
Date: Wed, 23 Sep 2009 14:36:27 +0000
Subject: [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1253716587.31.0.116018250453.issue6977@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Is there a way in getopt to define an option that takes an optional
argument?  I thought options either required args or did not accept them
at all.

----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:39:37 2009
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Sep 2009 14:39:37 +0000
Subject: [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1253716777.05.0.764201022057.issue6977@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Yes, that's true Doug. May be it should be explicitly stated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:43:16 2009
From: report at bugs.python.org (=?utf-8?q?Kuba_Ko=C5=84czyk?=)
Date: Wed, 23 Sep 2009 14:43:16 +0000
Subject: [issue1472251] pdb 'run' crashes when the it's first argument is
	non-string
Message-ID: <1253716996.5.0.51769831854.issue1472251@psf.upfronthosting.co.za>


Kuba Ko?czyk <jakamkon at users.sourceforge.net> added the comment:

Updated patch with tests and documentation.It fixes the issue by leaving
argument checking to exec and eval functions.The result is a more
readable error messages when invoking run/runeval with incorrect
arguments (see discussion above) and also ability to run pdb on an open
file objects.

----------
keywords: +patch
versions: +Python 2.4, Python 2.5, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14959/bdb-run.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1472251>
_______________________________________

From report at bugs.python.org  Wed Sep 23 16:43:47 2009
From: report at bugs.python.org (=?utf-8?q?Kuba_Ko=C5=84czyk?=)
Date: Wed, 23 Sep 2009 14:43:47 +0000
Subject: [issue1472251] pdb 'run' crashes when the it's first argument is
	non-string
Message-ID: <1253717027.45.0.545853271311.issue1472251@psf.upfronthosting.co.za>


Changes by Kuba Ko?czyk <jakamkon at users.sourceforge.net>:


Removed file: http://bugs.python.org/file1975/bdb-run.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1472251>
_______________________________________

From report at bugs.python.org  Wed Sep 23 17:07:31 2009
From: report at bugs.python.org (=?utf-8?q?Kuba_Ko=C5=84czyk?=)
Date: Wed, 23 Sep 2009 15:07:31 +0000
Subject: [issue1472251] pdb 'run' crashes when the it's first argument is
	non-string
Message-ID: <1253718451.46.0.455605684081.issue1472251@psf.upfronthosting.co.za>


Kuba Ko?czyk <jakamkon at users.sourceforge.net> added the comment:

BTW, patch is based on trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1472251>
_______________________________________

From report at bugs.python.org  Wed Sep 23 18:04:44 2009
From: report at bugs.python.org (Benjamin)
Date: Wed, 23 Sep 2009 16:04:44 +0000
Subject: [issue6979] Passing output arguments to an ActiveX application
In-Reply-To: <1253721884.72.0.921997932907.issue6979@psf.upfronthosting.co.za>
Message-ID: <1253721884.72.0.921997932907.issue6979@psf.upfronthosting.co.za>


New submission from Benjamin <benjamin.caron at laposte.net>:

Hi.

I hope I'm in the good thing to expose my problem...
I try to make a script in Python working under ControlDesk, a dSpace 
simulator.
In this script I call an ActiveX application given by an external 
software, System Monitor, to get some information from my ECU (Engine 
Control Unit).

I can access to the ActiveX, I can call functions but only ones which 
don't need output argument.
When I use functions which need only input argument, it's working 
perfectly.
If I want to use functions which need some output argument, I have a 
message error from Python...

========================================================================
Here is an example of a working script:
***************************************

import os
import win32com.client

if __name__ == '__main__':
    print ""
    Kit = "C:\\U\\TNR_MES_2009\\THR2RAT11BA01.m"
    
    SysMonApp = win32com.client.Dispatch("System Monitor API")
    if SysMonApp == None:
        print "Pas d'instance System Monitor"
    #endif
    Err = SysMonApp.SetLiveUpdates(True)
    if Err != 0:
        print Err
    #endif
    print "LiveUpdates Actif"
    Err = SysMonApp.MatlabImport(Kit)
    if Err !=0:
        print Err
    #endif
    print "Import kit .m termine"

    SysMonApp = None
    print "Fin du script"    
#endif
========================================================================

Here is an example of a NON-working script:
import os
import win32com.client
from ctypes import *

if __name__ == '__main__':
    print ""
    Kit = "C:\\U\\TNR_MES_2009\\THR2RAT11BA01.m"
    
    SysMonApp = win32com.client.Dispatch("System Monitor API")
    if SysMonApp == None:
        print "Pas d'instance System Monitor"
    #endif

    #OnlineSt = False
    OnlineSt = c_double()
    Err = SysMonApp.GetOnline(byref(OnlineSt))
    if Err != 0:
        print Err
    #endif
    if OnlineSt == True:
        print "ECU Online"
    else:
        print "ECU Offline"
    #endif

    SysMonApp = None
    print "Fin du script"    
#endif

========================================================================
The error message is:

Traceback (most recent call last):
  File "C:\Python26\Lib\site-
packages\pythonwin\pywin\framework\scriptutils.py", line 325, in 
RunScript
    exec codeObject in __main__.__dict__
  File "C:\U\TNR_MES_2009\EssaiSysMonSeul_Output_KO.py", line 16, in 
<module>
    Err = SysMonApp.GetOnline(byref(OnlineSt))
  File "<COMObject System Monitor API>", line 2, in GetOnline
TypeError: Objects of type 'CArgObject' can not be converted to a COM 
VARIANT
========================================================================

As you can see I use the ctype library to try pass output argument, 
using byref.
But I also try to pass argument directly under python, without ctypes:

    OnlineSt = False
    Err = SysMonApp.GetOnline(OnlineSt)

and I had the folowing error message:

Traceback (most recent call last):
  File "C:\Python26\Lib\site-
packages\pythonwin\pywin\framework\scriptutils.py", line 325, in 
RunScript
    exec codeObject in __main__.__dict__
  File "C:\U\TNR_MES_2009\EssaiSysMonSeul_Output_KO.py", line 16, in 
<module>
    Err = SysMonApp.GetOnline(OnlineSt)
  File "<COMObject System Monitor API>", line 2, in GetOnline
com_error: (-2147352571, 'Le type ne correspond pas.', None, 1)
========================================================================

The help for the activeX function explain that the output arguments 
need to be pass as pointer:

GetOnline 
Returns whether the ECU is online or not.
Arguments:
 bool* bResult - whether the ECU is online or offline. 
 



Do you have any idea to solve this problem?

Many thanks

Benjamin

----------
components: Library (Lib)
messages: 93043
nosy: benji13
severity: normal
status: open
title: Passing output arguments to an ActiveX application
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6979>
_______________________________________

From report at bugs.python.org  Wed Sep 23 18:13:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Sep 2009 16:13:26 +0000
Subject: [issue6979] Passing output arguments to an ActiveX application
In-Reply-To: <1253721884.72.0.921997932907.issue6979@psf.upfronthosting.co.za>
Message-ID: <1253722406.59.0.549023068481.issue6979@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you need general help, the bug tracker is not the right place where
to ask. If you think you have found a bug please follow these
instructions and explain clearly what the problem is:
http://www.python.org/dev/workflow/.

----------
nosy: +ezio.melotti
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6979>
_______________________________________

From report at bugs.python.org  Wed Sep 23 18:20:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Sep 2009 16:20:08 +0000
Subject: [issue6979] Passing output arguments to an ActiveX application
In-Reply-To: <1253721884.72.0.921997932907.issue6979@psf.upfronthosting.co.za>
Message-ID: <1253722808.8.0.177349586038.issue6979@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You might try asking on the ctypes-users mailing list:

https://lists.sourceforge.net/lists/listinfo/ctypes-users

I'll close this for now;  if, after discussing this on the ctypes-users 
list, you're reasonably sure that you've found a bug in Python itself 
(which is what this tracker is for), please come back and open another bug 
report.

----------
nosy: +mark.dickinson
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6979>
_______________________________________

From report at bugs.python.org  Wed Sep 23 19:44:21 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Wed, 23 Sep 2009 17:44:21 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1253727861.93.0.517412909051.issue5885@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5885>
_______________________________________

From report at bugs.python.org  Wed Sep 23 19:47:37 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Wed, 23 Sep 2009 17:47:37 +0000
Subject: [issue3212] ssl module - should test for a wrong cert
In-Reply-To: <1214505254.08.0.113211233471.issue3212@psf.upfronthosting.co.za>
Message-ID: <1253728057.98.0.74054835338.issue3212@psf.upfronthosting.co.za>


Thijs Triemstra <lists at collab.nl> added the comment:

Guess it can be closed then.

----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3212>
_______________________________________

From report at bugs.python.org  Wed Sep 23 19:49:53 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Wed, 23 Sep 2009 17:49:53 +0000
Subject: [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <1253728193.93.0.647575926752.issue6005@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6005>
_______________________________________

From report at bugs.python.org  Wed Sep 23 20:04:14 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Wed, 23 Sep 2009 18:04:14 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1253729054.83.0.243896208652.issue4434@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Wed Sep 23 20:30:22 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Wed, 23 Sep 2009 18:30:22 +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: <1253730622.88.0.120916975042.issue1143@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1143>
_______________________________________

From report at bugs.python.org  Wed Sep 23 20:30:25 2009
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 23 Sep 2009 18:30:25 +0000
Subject: [issue6980] fix ctypes build failure on armel-linux-gnueabi with
	-mfloat-abi=softfp
In-Reply-To: <1253730625.9.0.970320332999.issue6980@psf.upfronthosting.co.za>
Message-ID: <1253730625.9.0.970320332999.issue6980@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41443
should be imported.

I'm checking this in on the 2.6 branch for the upcoming 2.6.3 release.

----------
assignee: theller
components: ctypes
messages: 93047
nosy: doko, theller
severity: normal
status: open
title: fix ctypes build failure on armel-linux-gnueabi with -mfloat-abi=softfp
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6980>
_______________________________________

From report at bugs.python.org  Wed Sep 23 21:35:04 2009
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 23 Sep 2009 19:35:04 +0000
Subject: [issue6981] locale.getdefaultlocale() envvars default code and
	documentation mismatch
In-Reply-To: <1253734503.58.0.404575668112.issue6981@psf.upfronthosting.co.za>
Message-ID: <1253734503.58.0.404575668112.issue6981@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

The default list of locale.getdefaultlocale() is documented to be the
one of GNU gettext; in the source docs in Python 2.7 trunk:

    "envvars defaults to the search path used in GNU gettext; it must
     always contain the variable name 'LANG'."

...and at http://docs.python.org/dev/library/locale.html in addition to
that:

    "The GNU gettext search path contains 'LANGUAGE', 'LC_ALL',
     'LC_CTYPE', and 'LANG', in that order."

This is correct, cf.
http://www.gnu.org/software/gettext/manual/gettext.html#Locale-Environment-Variables

However, the code in locale.py does not match the documentation; the
patch in issue #1166948 (svn r39572) moved LANGUAGE to the end of the
list.  I suggest putting it back at the beginning as documented (the
other change in r39572 is ok).

The py3k branch appears to have the same problem.

----------
components: Library (Lib)
messages: 93048
nosy: scop
severity: normal
status: open
title: locale.getdefaultlocale() envvars default code and documentation mismatch
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6981>
_______________________________________

From report at bugs.python.org  Wed Sep 23 22:31:41 2009
From: report at bugs.python.org (egreen)
Date: Wed, 23 Sep 2009 20:31:41 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>


New submission from egreen <egreen at operamail.com>:

make clean and make distclean don't remove the grammar pickles generated
by load_grammar in Lib/lib2to3/pgen2/driver.py
(Lib/lib2to3/Grammar3.2.0.alpha.0.pickle,
Lib/lib2to3/PatternGrammar3.2.0.alpha.0.pickle).

Proposed patch attached. It removes all *.pickle files, which I assume
is safe. (Patch also corrects a comment.)

----------
components: 2to3 (2.x to 3.0 conversion tool), Build
files: clean-pickles.patch
keywords: patch
messages: 93049
nosy: egreen
severity: normal
status: open
title: make clean does not remove pickle files
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14960/clean-pickles.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 02:23:43 2009
From: report at bugs.python.org (Stef Walter)
Date: Thu, 24 Sep 2009 00:23:43 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>


New submission from Stef Walter <stef at memberwebs.com>:

In Lib/distutils/util.py in the get_platform() function there's OS 
specific code to create a string which describes the current platform. 
This usually includes the OS + version + arch. 

FreeBSD specific code is missing from this function. Currently 
get_platform() returns a string specific to the security patch level of 
freebsd. For example:

freebsd-7.2-RELEASE-p3-i386

This results in eggs that only work on a specific patch level release of 
FreeBSD and are not portable between (for example) 7.2-RELEASE-p2 and 
7.2-RELEASE-p3.

However FreeBSD is actually binary compatible within a major version 
number. For example 7.1 and 7.2 are binary compatible.

This patch adds freebsd specific code to get_platform() after which it 
will return a string like:

freebsd-7-i386

----------
assignee: tarek
components: Distutils
files: patch-python-distutils-osrel.diff
keywords: patch
messages: 93050
nosy: stefw, tarek
severity: normal
status: open
title: Add specific get_platform() for freebsd
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14961/patch-python-distutils-osrel.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 03:03:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Sep 2009 01:03:54 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253754234.64.0.632790833364.issue6982@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson
priority:  -> low
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 06:42:49 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 24 Sep 2009 04:42:49 +0000
Subject: [issue6272] Upgrading xml.etree to ElementTree 1.3
In-Reply-To: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>
Message-ID: <1253767369.32.0.835359666474.issue6272@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is duplicate of Issue1143

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6272>
_______________________________________

From report at bugs.python.org  Thu Sep 24 07:41:45 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Thu, 24 Sep 2009 05:41:45 +0000
Subject: [issue6984] typo in Unicode HOWTO
In-Reply-To: <1253770905.47.0.191308978171.issue6984@psf.upfronthosting.co.za>
Message-ID: <1253770905.47.0.191308978171.issue6984@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

at http://docs.python.org/dev/3.0/howto/unicode.html:
Uniode should be Unicode

----------
assignee: georg.brandl
components: Documentation
messages: 93052
nosy: Yinon, georg.brandl
severity: normal
status: open
title: typo in Unicode HOWTO
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6984>
_______________________________________

From report at bugs.python.org  Thu Sep 24 07:44:48 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Thu, 24 Sep 2009 05:44:48 +0000
Subject: [issue6984] typo in Unicode HOWTO
In-Reply-To: <1253770905.47.0.191308978171.issue6984@psf.upfronthosting.co.za>
Message-ID: <1253771088.33.0.148649878686.issue6984@psf.upfronthosting.co.za>


Yinon Ehrlich <yinoneh at users.sourceforge.net> added the comment:

oops, appear in http://docs.python.org/3.1/howto/unicode.html too...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6984>
_______________________________________

From report at bugs.python.org  Thu Sep 24 07:53:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 24 Sep 2009 05:53:34 +0000
Subject: [issue6984] typo in Unicode HOWTO
In-Reply-To: <1253770905.47.0.191308978171.issue6984@psf.upfronthosting.co.za>
Message-ID: <1253771614.55.0.207193674221.issue6984@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r75043.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6984>
_______________________________________

From report at bugs.python.org  Thu Sep 24 09:11:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 07:11:14 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253776274.15.0.612454377456.issue6982@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't think it is safe to remove all *.pickle files in the source 
directory;  even if there aren't any other useful .pickle files right now, 
there could be in the future (e.g. for pickle testing).

I'd prefer something more targeted.

Are these .pickle files generated during the build process, or just during 
testing?  Maybe it should be the responsibility of the 2to3 tests to clean 
up after themselves?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 09:30:15 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 24 Sep 2009 07:30:15 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <4AB90123.7050500@egenix.com>
Message-ID: <4ABA5541.6090207@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The codec currently doesn't look at the base at all - and shouldn't
> need to:
> 
> It simply converts input characters that have a decimal digit value
> associated with them, to the usual ASCII digits in preparation
> for parsing them using the standard number parsing tools we have in
> Python.

Right. And as such, it shouldn't stop with digit 9, but continue into
digits a, b, c, and so on, as appropriate.

> This is to support number representations using non-ASCII code
> points for digits (e.g. Japanese or Sanskrit numbers)

Notice that it also supports bases other than 10:

80

So calling it "decimal" is a misnomer.

> Also note that we already have a hex codec in Python 2.x
> which converts between the hex representations of a string
> and its regular form. This was removed in 3.x for some reason
> I don't understand (probably just an oversight).

The hex codec doesn't have to do anything with number conversions;
nor does it have to do with character encodings. To introduce it was
a mistake in Python 2.x which has been fixed in 3.x (by removing
it and other similar "codecs", such as rot13).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Thu Sep 24 09:30:18 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 24 Sep 2009 07:30:18 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1253616536.4.0.145439176425.issue6834@psf.upfronthosting.co.za>
Message-ID: <4ABA566C.9010003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This version uses posix_spawn rather than execv to start the real 
> interpreter. 

In what way is that better? It creates a new process (IIUC); therefore,
I think that using it is worse than using execv. Anybody killing the
pythonw process would only kill the wrapper.

> The main advantage of the new implementation is that 'arch 
> -ppc pythonw' works as expected, with the current version of pythonw the 
> 'arch' command only affects the pythonw executable and not the real 
> interpreter.

I suppose this would also be possible through execv?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Thu Sep 24 10:39:06 2009
From: report at bugs.python.org (egreen)
Date: Thu, 24 Sep 2009 08:39:06 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253781546.26.0.432227523486.issue6982@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

These .pickle files aren't created by the tests themselves, but they do
show up after running 'make test', or more specifically after running
'./python Lib/test/regrtest.py -v test_lib2to3'.

This is because a grammar generated from a .txt grammar file is cached
as a pickle for faster access by load_grammar in
Lib/lib2to3/pgen2/driver.py. A pickle file then ends up in the same
directory as the .txt file.

IMHO, though it may be preferable to remove just the pickle files in
Lib/lib2to3, it should never be required for tests to have pickle files
already available in the source tree. Instead, the test should create a
temporary pickle file, e.g. from a bytes object. Furthermore, binary
files shouldn't be versioned without good reason. Thus, removing all
pickle files should be safe for the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 10:40:15 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Sep 2009 08:40:15 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <4ABA5541.6090207@v.loewis.de>
Message-ID: <4ABB30A0.4050803@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> The codec currently doesn't look at the base at all - and shouldn't
>> need to:
>>
>> It simply converts input characters that have a decimal digit value
>> associated with them, to the usual ASCII digits in preparation
>> for parsing them using the standard number parsing tools we have in
>> Python.
> 
> Right. And as such, it shouldn't stop with digit 9, but continue into
> digits a, b, c, and so on, as appropriate.

I don't think that's needed. The codec already passes those
through as-is.

>> This is to support number representations using non-ASCII code
>> points for digits (e.g. Japanese or Sanskrit numbers)
> 
> Notice that it also supports bases other than 10:
> 
> 80
> 
> So calling it "decimal" is a misnomer.

Not really: _PyUnicode_ToDecimalDigit() is used for the
conversion and that API explicitly only returns integer
values for code points that map to the digits 0-9 - at
least that's how it was originally written (see the code
in Python 1.6 which makes this explicit).

If it returns values outside that range, that's a bug
and needs to be fixed, since it would cause the codec
to fail. It is designed to only work on digits, not
arbitrary decimals.

>> Also note that we already have a hex codec in Python 2.x
>> which converts between the hex representations of a string
>> and its regular form. This was removed in 3.x for some reason
>> I don't understand (probably just an oversight).
> 
> The hex codec doesn't have to do anything with number conversions;
> nor does it have to do with character encodings. To introduce it was
> a mistake in Python 2.x which has been fixed in 3.x (by removing
> it and other similar "codecs", such as rot13).

That's your particular view of things. It's not mine and never
was the basis of the codec design.

Codecs in Python are open to work on arbitrary types and
it's well possible to have codecs that return the same type
as their input.

The hex codec in Python 2.x is a very useful and handy
codec and it's used a lot.

It should be added back again - after all, even by your
restrictive view of codecs in Python only serving as a way to
do character encodings, it is a valid character encoding -
that of Latin-1 code points to a two-byte HEX representation
and vice-versa.

Just like rot-13 and most of the others that were apparently
removed (uu, base64, quoted-printable, zip, bz2).

BTW: I noticed that idna and punycode were not removed...
even though they fall into the same category as the hex
codec.

I guess we should have a discussion about this on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Thu Sep 24 11:17:41 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Sep 2009 09:17:41 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <4ABB396C.5070804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stef Walter wrote:
> 
> New submission from Stef Walter <stef at memberwebs.com>:
> 
> In Lib/distutils/util.py in the get_platform() function there's OS 
> specific code to create a string which describes the current platform. 
> This usually includes the OS + version + arch. 
> 
> FreeBSD specific code is missing from this function. Currently 
> get_platform() returns a string specific to the security patch level of 
> freebsd. For example:
> 
> freebsd-7.2-RELEASE-p3-i386
> 
> This results in eggs that only work on a specific patch level release of 
> FreeBSD and are not portable between (for example) 7.2-RELEASE-p2 and 
> 7.2-RELEASE-p3.
> 
> However FreeBSD is actually binary compatible within a major version 
> number. For example 7.1 and 7.2 are binary compatible.
> 
> This patch adds freebsd specific code to get_platform() after which it 
> will return a string like:
> 
> freebsd-7-i386

I think this is more a problem with easy_install than with
distutils itself.

get_platform() is meant to return a platform string, nothing
more, nothing less.

It is more meant for human consumption than for scripts to
use as basis for checking whether a particular platform
is binary compatible to what the user wants to install
a distribution archive to.

What we could do is provide a new distutils API
binary_compatible_platform() which takes the platform string
as used in the distribution archive and compares it to the
one returned by distutils on the target system.

Note that there are various level of compatibility to
consider here:

 * whether the ABI is the same (binary compatible)
 * whether the code is 32-bit and needs to run on a 64-bit
   system
 * whether the typically installed software base is
   the same
 * whether the target system provides a compatibility layer
   which can be used or not
 * whether the distribution provides code for more than
   one platform (e.g. Mac universal builds), so that it'll
   run on more than just one architecture

It is usually easier for the user to decide by looking at
the file name whether a certain package is suitable or not
than to have some script know about all the differences
between the various OS versions.

Some examples for get_platform() strings which are in fact
compatible:

darwin-8.11.0-Power_Macintosh (the Python 2.3 way)
macosx-10.4-fat (the Python 2.5+ way)
macosx-10.4-ppc (actually "fat", but not identified as such
                 due to a bug in distutils for Python 2.4)

Aside: For eGenix we have decided to simply drop the get_platform()
check in our prebuilt archives altogether - there are just too
many dimensions to the problem. Instead, we use the sys.platform
variable which provides a much more practical (though, not perfect)
solution to the problem of detecting incompatibilities early
on in the installation process.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 11:34:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 09:34:55 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253784895.83.0.455053885769.issue6982@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> IMHO, though it may be preferable to remove just the pickle files in
> Lib/lib2to3,

Sounds reasonable.

> it should never be required for tests to have pickle files
> already available in the source tree.

Well, I don't know about 'should', but the current tests already do
make use of pickle files in the source tree:  see Lib/test/*.pck.
So there are already versioned pickle files (but not .pickle files :-).

----------
versions: +Python 2.6, Python 2.7 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 12:09:32 2009
From: report at bugs.python.org (egreen)
Date: Thu, 24 Sep 2009 10:09:32 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253786972.82.0.282562818754.issue6982@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

You are right. Guess I was being a little too dogmatic. :-)

I hadn't found those .pck files, because I was only looking for binary
files.

Here's a new patch proposal.

----------
Added file: http://bugs.python.org/file14962/clean-grammar-pickles.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 12:38:14 2009
From: report at bugs.python.org (Krzysztof Szawala)
Date: Thu, 24 Sep 2009 10:38:14 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>


New submission from Krzysztof Szawala <kszawala at slb.com>:

range() method fails with the following error message:

"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items
"

when passing a valid integer value of 9999999999.
This value is obtained from OptParse command-line option as a valid 
ingeter.

Applies to both Windows and Linux (32 and 64-bit).

----------
components: Interpreter Core
messages: 93063
nosy: kszawala
severity: normal
status: open
title: range() fails with long integers
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________

From report at bugs.python.org  Thu Sep 24 12:54:49 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 24 Sep 2009 10:54:49 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253789689.22.0.458334720703.issue6985@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This doesn't crash the interpreter, so I'm changing it to "behavior".

The number of items in a range() must fit into a native int.

What are you doing with the range? Could you use xrange instead?

----------
nosy: +eric.smith
resolution:  -> wont fix
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________

From report at bugs.python.org  Thu Sep 24 12:58:44 2009
From: report at bugs.python.org (Jan Hosang)
Date: Thu, 24 Sep 2009 10:58:44 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1253789924.92.0.604568288314.issue5395@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I attached a path for raising IOErrors in fromfile. I also added a 
testcase which failed before.

The test opens a file and closes the file with os.close(fd) without 
telling the file object, so fromfile doesn't notice it's reading from a 
file that is actually closed.

----------
keywords: +patch
nosy: +chuck
Added file: http://bugs.python.org/file14963/array_ioerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5395>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:08:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 11:08:58 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253790538.46.0.221652779675.issue6985@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I *think* range uses long internally, so 9999999999 should be okay on an
LP64 machine.  Except that of course the range() result must also fit in
memory: on a 64-bit machine range(9999999999) would need more than 300
Gb of memory.  (That's 32 bytes per entry:  24 bytes for each integer
and 8 bytes for the list pointer.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:14:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 11:14:43 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253790883.35.0.985731904293.issue6982@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks!  I'll apply this later today, unless Benjamin gets there first. :)

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:21:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Sep 2009 11:21:06 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

scanner_init() and encoder_init() don't manage errors correctly.

scanner_init() gets context.encoding argument without checking context
type, nor GetAttrString() error. It should check for NULL result...
which is done in the same function for other attributes (strict,
object_hook, object_pairs_hook, parse_float, parse_int, parse_constant).

Example to reproduce the crash:
   import _json
   _json.make_scanner(1)

encoder_init() copies a refence (for each argument) without incrementing
the reference counter. And then encoder_clear() decrements the
reference, counter, which may crash Python.

Example to reproduce the crash:
   import _json
   _json.make_encoder(
           (False, True),
           -826484143518891896,
           -56.0,
           "a",
       )
   # do anything creating/destroying new objects
   " abc ".strip()
   len(" xef ".strip())

Attached patches for the crashes.

----------
files: _json_encoder_init.patch
keywords: patch
messages: 93068
nosy: haypo
severity: normal
status: open
title: _json crash on scanner/encoder initialization error
Added file: http://bugs.python.org/file14964/_json_encoder_init.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:21:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Sep 2009 11:21:19 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1253791279.62.0.780227289893.issue6986@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file14965/_json_scanner_init.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:23:28 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Sep 2009 11:23:28 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1253791408.71.0.85939686046.issue6986@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About _json_encoder_init.patch, an alternative patch is to write
arguments references (addresses) in local variables, and only copy them
on success. Something like:
  PyObject *arg;
  if (!PyTuple_ParseArgs(..., &arg)) return NULL;
  Py_INCREF(arg);
  self->arg = arg;

I prefered to write a shorter patch.

Tell me if you prefer the alternative fix, and if you would like unit tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:25:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 11:25:19 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253791519.91.0.212844425792.issue6985@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Might it make more sense for this range call to return a MemoryError
rather than an OverflowError, on 64-bit machines?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________

From report at bugs.python.org  Thu Sep 24 13:36:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 11:36:02 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253792162.11.0.510010328214.issue6985@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Mark]
> I *think* range uses long internally

Aargh!  Sorry, Eric.  I take it back.  *xrange* uses longs internally
(and used to use ints once upon a time, IIRC), but there's a weird mix
of int and long in builtin_range that doesn't make any sense to me.  I
suspect it's historical, and may have to do both with the xrange
int->long switch and the int -> Py_ssize_t switch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________

From report at bugs.python.org  Thu Sep 24 14:05:23 2009
From: report at bugs.python.org (dorina)
Date: Thu, 24 Sep 2009 12:05:23 +0000
Subject: [issue6987] Idle not start
In-Reply-To: <1253793923.16.0.575458471833.issue6987@psf.upfronthosting.co.za>
Message-ID: <1253793923.16.0.575458471833.issue6987@psf.upfronthosting.co.za>


New submission from dorina <dorina_n2005 at yahoo.com>:

Hello!
I installed Python31 on WinXp,but IDLE doesn't start. I tried at 
command prompt 
python Lib\idlelib\idle.py
the result is in attachement.
please help...
thanks.

----------
components: IDLE
files: err1.JPG
messages: 93072
nosy: dorina_n2005
severity: normal
status: open
title: Idle not start
versions: Python 3.1
Added file: http://bugs.python.org/file14966/err1.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6987>
_______________________________________

From report at bugs.python.org  Thu Sep 24 15:31:57 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Sep 2009 13:31:57 +0000
Subject: [issue6987] Idle not start
In-Reply-To: <1253793923.16.0.575458471833.issue6987@psf.upfronthosting.co.za>
Message-ID: <1253799117.37.0.24851943895.issue6987@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a duplicate of issue5528.
The fix is to remove the TCL_LIBRARY environment variable.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Unable to launch IDLE on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6987>
_______________________________________

From report at bugs.python.org  Thu Sep 24 15:54:09 2009
From: report at bugs.python.org (Bill Fenner)
Date: Thu, 24 Sep 2009 13:54:09 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output with
	varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>


New submission from Bill Fenner <fenner at gmail.com>:

In python 2.5, shlex handled unicode input fine:

Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51) 
[GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split( u'Hello, World!' )
['Hello,', 'World!']

In python 2.6, shlex turns unicode input into UCS-4 output, thus utterly
confusing execl:

Python 2.6 (r26:66714, Jun  8 2009, 16:07:29)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split( u'Hello, World' )
['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00',
'\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00']

Even weirder, the two return strings have different byte order (see
'H\x00\x00\x00' vs. '\x00\x00\x00W'!)

----------
components: Library (Lib)
messages: 93074
nosy: fenner
severity: normal
status: open
title: shlex.split() converts unicode input to UCS-4 output with varying byte order
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 16:00:35 2009
From: report at bugs.python.org (Bill Fenner)
Date: Thu, 24 Sep 2009 14:00:35 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output with
	varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253800835.52.0.0608970540856.issue6988@psf.upfronthosting.co.za>


Bill Fenner <fenner at gmail.com> added the comment:

A colleague pointed out that the bad behavior was introduced in 2.5.2:

Python 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split( u"Hello, World!" )
['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00',
'\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00!\x00\x00\x00']

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 16:19:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Sep 2009 14:19:20 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1253801960.22.0.135377057292.issue6986@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Thu Sep 24 16:40:23 2009
From: report at bugs.python.org (Stef Walter)
Date: Thu, 24 Sep 2009 14:40:23 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1253803223.95.0.856526236031.issue6983@psf.upfronthosting.co.za>


Stef Walter <stef at memberwebs.com> added the comment:

I agree with your comments, and the solution you're proposing solves the 
problem (and several others) for the long term. 

However in the short term, could this patch be committed? Most other OS's 
(including openbsd and netbsd) have OS specific code in get_platform(). 
FreeBSD is notably missing from that function. 

Obviously this would not preclude work on a better all encompassing 
solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 16:43:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Sep 2009 14:43:01 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1253803381.31.0.625689965582.issue6986@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Unit tests are definitely desireable!
I would also like the "alternate approach" fix, it would probably be
cleaner.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Thu Sep 24 17:56:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Sep 2009 15:56:59 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253803223.95.0.856526236031.issue6983@psf.upfronthosting.co.za>
Message-ID: <4ABB9705.1030908@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stef Walter wrote:
> 
> Stef Walter <stef at memberwebs.com> added the comment:
> 
> I agree with your comments, and the solution you're proposing solves the 
> problem (and several others) for the long term. 
> 
> However in the short term, could this patch be committed? Most other OS's 
> (including openbsd and netbsd) have OS specific code in get_platform(). 
> FreeBSD is notably missing from that function. 

The code in get_platform() tries to gather as much information as
possible regarding a platform, rather than limiting the amount of
information.

That's why there are so many entries for the various OSes.

Please contact the maintainer of easy_install to get it fixed
to handle the specific FreeBSD case. For other systems they will
likely have to apply similar patches, e.g. for Mac OS X, Sun,
AIX, etc. - all of these include version and release information
in the get_platform() output.

Regarding a short term fix, there's no a lot we can do: the next
Python release is 2.7 and changing this for 2.6 is out of the question,
since it would break other tools that rely on the established
naming scheme.

easy_install has a different release cycle, so it's easier
to get a fix for it, or just apply one yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 18:12:17 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Sep 2009 16:12:17 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output with
	varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253808737.23.0.0938175769721.issue6988@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'll take the opposite point of view:
the bad behavior was introduced with 2.5.1 (issue1548891, r52302), and
reverted for 2.5.2 because "it broke backwards compatibility with
arbitrary read buffers" (issue1730114, r53831)

The difference is in cStringIO:

>>> from cStringIO import StringIO
>>> StringIO(u"Hello, World!").read()
'H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00
\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00!\x00\x00\x00'

The byte order is not different in the two strings: but u" " becomes 
" \x00\x00\x00" and the three zeros are copied into the second item.

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 19:21:19 2009
From: report at bugs.python.org (Bill Fenner)
Date: Thu, 24 Sep 2009 17:21:19 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output with
	varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253812879.46.0.140044343394.issue6988@psf.upfronthosting.co.za>


Bill Fenner <fenner at gmail.com> added the comment:

so, just to be clear, your position is that the output of shlex.split(
u'Hello, World!' ) is *supposed* to be
['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00',
'\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00']?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 19:29:20 2009
From: report at bugs.python.org (Stef Walter)
Date: Thu, 24 Sep 2009 17:29:20 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1253813360.83.0.839189485471.issue6983@psf.upfronthosting.co.za>


Stef Walter <stef at memberwebs.com> added the comment:

Other OSs have special cases in get_platform() to specifically limit the 
amount of code, and make proper decisions with regard to package 
compatibility. 

Here's an example this commit for Mac OS X: http://svn.python.org/view?
view=rev&revision=67988

It was discussed here at this issue: http://bugs.python.org/issue4064

Another example is how linux has no version information at all (ie: 
linux-i586). Perhaps this is why the easy_install authors thought their 
package system worked. They only tested it on linux?

Yes I agree that obviously this cannot be changed for 2.6. But it would 
be great to get this code in for python 2.7

Anyway, this is ultimately your call, since I don't have the 50,000 foot 
view over the entire situation. 

FWIW, I've had to patch python in a very large set of client 
installations. This patch has become a routine in order to unbreak 
python wrt to platform dependent packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 19:34:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Sep 2009 17:34:40 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output with
	varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253813680.98.0.24252161733.issue6988@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hm, while the StringIO behaviour supposedly cannot be changed for
backwards-compatibility reasons, we can probably improve shlex behaviour
with unicode strings.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 19:48:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Sep 2009 17:48:48 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output with
	varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253814528.52.0.243696782445.issue6988@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

(Presented this way, "my opinion" becomes difficult to stand...
OTOH the docs say that the module does not support Unicode, so it's not
strictly a bug)
http://docs.python.org/library/shlex.html

Yes, shlex could be improved and encode unicode strings to ascii.

----------
resolution: wont fix -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 20:17:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Sep 2009 18:17:59 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output
	with	varying byte order
In-Reply-To: <1253814528.52.0.243696782445.issue6988@psf.upfronthosting.co.za>
Message-ID: <4ABBB811.2070204@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:
> 
> (Presented this way, "my opinion" becomes difficult to stand...
> OTOH the docs say that the module does not support Unicode, so it's not
> strictly a bug)
> http://docs.python.org/library/shlex.html
> 
> Yes, shlex could be improved and encode unicode strings to ascii.

I'd suggest to convert Unicode input to a string using an
optional encoding parameter which defaults to 'utf-8' (most
shells nowadays default to UTF-8).

This is only a compromise, though, albeit a practical one.
POSIX has the notion of a portable character set:

http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap06.html#tagtcjh_3

which is pretty much the same as ASCII. Any ASCII compatible
encoding is then allowed via variable length encodings (see
further down on that page).

----------
nosy: +lemburg
title: shlex.split() converts unicode input to UCS-4 output with varying byte order -> shlex.split() converts unicode input to UCS-4 output with	varying byte order

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 20:25:09 2009
From: report at bugs.python.org (Bill Fenner)
Date: Thu, 24 Sep 2009 18:25:09 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253816709.15.0.379122284098.issue6988@psf.upfronthosting.co.za>


Bill Fenner <fenner at gmail.com> added the comment:

Sorry, I didn't read the web documentation, only the module
documentation, which doesn't mention Unicode.  I'd agree that since it's
a documented behavior, this bug can become:

- an RFE for shlex to handle Unicode
- meanwhile, if there will be any releases before that happens, an RFE
for the module documentation to mention the lack of Unicode support

----------
title: shlex.split() converts unicode input to UCS-4 output with	varying byte order -> shlex.split() converts unicode input to UCS-4 output

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Thu Sep 24 20:51:42 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 24 Sep 2009 18:51:42 +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: <1253818302.49.0.128417750849.issue4947@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Thu Sep 24 20:53:06 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Sep 2009 18:53:06 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253813360.83.0.839189485471.issue6983@psf.upfronthosting.co.za>
Message-ID: <4ABBC04B.3080902@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stef Walter wrote:
> Other OSs have special cases in get_platform() to specifically limit the 
> amount of code, and make proper decisions with regard to package 
> compatibility. 
>
> Here's an example this commit for Mac OS X: http://svn.python.org/view?
> view=rev&revision=67988
> 
> It was discussed here at this issue: http://bugs.python.org/issue4064

Well, if you try to install .egg files built as universal binaries
on a system that uses a non-SDK build of Python on a PPC system,
you'll have a similar problem.

easy_install will look for '...-ppc', but the file is name '...-fat'.

But you do have a point: the '10.4' is actually an indicator for
the SDK version, not the version of the OS where the package
was built.

> Another example is how linux has no version information at all (ie: 
> linux-i586).

Right... the Linux major version doesn't change that often,
while the minor ones do change very often and don't really
give the user any useful information w/r to Python extensions.

As a result, using "Linux-2.6.22.19-0.4-default" in the name
would cause more user concern than necessary.

> Perhaps this is why the easy_install authors thought their 
> package system worked. They only tested it on linux?

Probably. Most .eggs are Python-only, so they don't even need a
platform string. The others are mostly for Windows.

> Yes I agree that obviously this cannot be changed for 2.6. But it would 
> be great to get this code in for python 2.7
> 
> Anyway, this is ultimately your call, since I don't have the 50,000 foot 
> view over the entire situation. 

Is that binary compatibility scheme documented somewhere ?

If so, we could switch to '%s-%s' % (sys.platform, machine)
for Python 2.7.

> FWIW, I've had to patch python in a very large set of client 
> installations. This patch has become a routine in order to unbreak 
> python wrt to platform dependent packages.

Since this only affects easy_install/setuptools, it's probably
easier to just create a patched egg for that and then use it
with the normal Python installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 20:58:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 18:58:18 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1253818698.06.0.399208712544.issue6970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for py3k.  I'd appreciate it if some other committer could 
check it for sanity.

----------
keywords: +patch
Added file: http://bugs.python.org/file14967/issue6970.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________

From report at bugs.python.org  Thu Sep 24 21:04:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 19:04:46 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1253819086.09.0.782302748791.issue6970@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +needs review -patch
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________

From report at bugs.python.org  Thu Sep 24 21:07:35 2009
From: report at bugs.python.org (Ashish)
Date: Thu, 24 Sep 2009 19:07:35 +0000
Subject: [issue6989] Python-2.6.2
In-Reply-To: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
Message-ID: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>


New submission from Ashish <pimple9 at gmail.com>:

I am getting error while compiling python-2.6.2
OS - Solaris 10 8/07 s10s_u4wos_12b SPARC
bash-3.00$ isainfo -v
64-bit sparcv9 applications
        asi_blk_init
32-bit sparc applications
        asi_blk_init v8plus div32 mul32
Paths and defined
PATH=/usr/local/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/sfw/bin:/usr/sfw/sbin:/opt/SUNWspci/bin:/usr/ccs/bin:/usr/bin:$PATH
export LD_LIBRARY_PATH="/usr/lib/sparcv9:/usr/local/lib/sparcv9"
export LDFLAGS="-mcpu=v9 -m64"
export LDDFLAGS="-mcpu=v9 -m64 -G"
export CC="gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"

Configure seems to be runs fine. ( Attched File for configure )
 sudo ./configure --with-universal-archs="64 bit"
--prefix=/opt/Python-2.6.2/

But getting error after running make
bash-3.00$ sudo make
\gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 -c -fno-strict-aliasing
-DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include 
-DPy_BUILD_CORE -o Objects/floatobject.o Objects/floatobject.c
/var/tmp//ccBDYDRE.s: Assembler messages:
/var/tmp//ccBDYDRE.s:7339: Error: Illegal operands: There are only 32
single precision f registers; [0-31]
*** Error code 1
make: Fatal error: Command failed for target `Objects/floatobject.o'

Please advice.

----------
components: Installation
files: Configure.txt
messages: 93088
nosy: ashish
severity: normal
status: open
title: Python-2.6.2
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14968/Configure.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6989>
_______________________________________

From report at bugs.python.org  Thu Sep 24 21:28:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 19:28:45 +0000
Subject: [issue6982] make clean does not remove pickle files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253820525.45.0.760558563294.issue6982@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed in r75047 (trunk).  Merged in r75048 (release26-maint), r75049 
(py3k) and r75050 (release31-maint).

----------
assignee:  -> mark.dickinson
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________

From report at bugs.python.org  Thu Sep 24 21:37:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 19:37:44 +0000
Subject: [issue6989] Python-2.6.2
In-Reply-To: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
Message-ID: <1253821064.05.0.140224998476.issue6989@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If you do a Google search for that particular error message ('There are 
only 32 single ...'), the results suggest that this is a known problem 
with gcc and/or gas on Solaris.

Does removing the -O3 optimization flag make any difference?  (Try 
removing all occurrences of -O3 from the configure file before 
configuring.)

In any case, I suspect this is something Python can't do much about.

----------
nosy: +mark.dickinson
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6989>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:05:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 20:05:45 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253822745.84.0.43198987628.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to be on the safe side, I changed the PyLong_Check(ob) check to PyLong_CheckExact(ob) || PyBool_Check(ob), in r75051.  Without this, one 
can get different results for 'x in range(10)' and 'x in list(range(10))' 
if x is an instance of a subclass of int:

Python 3.2a0 (py3k:75050, Sep 24 2009, 20:56:13) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(int):
...     def __eq__(self, other): return True
... 
>>> C(11) in range(10)
False
>>> C(11) in list(range(10))
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:15:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 20:15:46 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253823346.08.0.739026489339.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unassigning myself since I don't intend to do anything myself about 
xrange.__contains__ in 2.x.  (But I'll happily review patches.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:16:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 20:16:02 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1253823362.39.0.397039224472.issue1766304@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:18:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Sep 2009 20:18:13 +0000
Subject: [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1253823493.36.0.0157699936652.issue6872@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for working on this, Ronald.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6872>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:22:29 2009
From: report at bugs.python.org (Stef Walter)
Date: Thu, 24 Sep 2009 20:22:29 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <4ABBC04B.3080902@egenix.com>
Message-ID: <4ABBD505.20507@memberwebs.com>


Stef Walter <stef at memberwebs.com> added the comment:

Marc-Andre Lemburg wrote:
> Is that binary compatibility scheme documented somewhere ?

Not sure, it's been referred to and adhered to many times in the FreeBSD
community, but I'm not sure where it's documented. I'll ask around on
the FreeBSD mailing lists and post my findings here.

FWIW, the freebsd kernel and package system have options specifically
for compatibility with previous major versions. ie: FreeBSD 8 has
COMPAT_FREEBSD7 and COMPAT_FREEBSD6 kernel options, and has
misc/compat7x and misc/compat6x libraries available for install. But
again, I'll let you know for sure.

>> FWIW, I've had to patch python in a very large set of client 
>> installations. This patch has become a routine in order to unbreak 
>> python wrt to platform dependent packages.
> 
> Since this only affects easy_install/setuptools, it's probably
> easier to just create a patched egg for that and then use it
> with the normal Python installation.

True, I could give that a shot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:53:27 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 24 Sep 2009 20:53:27 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253825607.72.0.920103988458.issue6985@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Both range and xrange were mucked with so much just before and during py3k 
development that I am sure odd inconsistencies of what they use internally 
are oversights.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________

From report at bugs.python.org  Thu Sep 24 22:59:35 2009
From: report at bugs.python.org (Ashish)
Date: Thu, 24 Sep 2009 20:59:35 +0000
Subject: [issue6989] Python-2.6.2
In-Reply-To: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
Message-ID: <1253825975.57.0.0805141992671.issue6989@psf.upfronthosting.co.za>


Ashish <pimple9 at gmail.com> added the comment:

I added vaiable as 
export CXX="gcc -q64"
then run 
sudo ./configure --with-universal-archs="64 bit" --prefix=/opt/Python-2.6.2/
After completion of configure I removed "O3" from makefile,
then run
sudo make
It seems to be run fine.
But after make install i get error as 
Compiling /opt/Python-2.6.2//lib/python2.6/xml/sax/expatreader.py ...
Compiling /opt/Python-2.6.2//lib/python2.6/xml/sax/handler.py ...
Compiling /opt/Python-2.6.2//lib/python2.6/xml/sax/saxutils.py ...
Compiling /opt/Python-2.6.2//lib/python2.6/xml/sax/xmlreader.py ...
Compiling /opt/Python-2.6.2//lib/python2.6/xmllib.py ...
Compiling /opt/Python-2.6.2//lib/python2.6/xmlrpclib.py ...
Compiling /opt/Python-2.6.2//lib/python2.6/zipfile.py ...
*** Error code 1
make: Fatal error: Command failed for target `libinstall'


I need to change variable with 
export LD_LIBRARY_PATH="L/usr/lib/sparcv9:/usr/local/lib/sparcv9
R/opt/Python-2.6.2/lib"
Please suggest.
Thanks for cooperation and guideline.
I feel we are near to resolve the issue.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6989>
_______________________________________

From report at bugs.python.org  Thu Sep 24 23:09:05 2009
From: report at bugs.python.org (Stef Walter)
Date: Thu, 24 Sep 2009 21:09:05 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1253826545.38.0.629663181047.issue6983@psf.upfronthosting.co.za>


Stef Walter <stef at memberwebs.com> added the comment:

About FreeBSD ABI compatibility between minor versions:

Julian Elischer wrote:
> It is a policy of the project but I don't think our policies are 
> written down as such. I think you will find it referenced in
> many places in a sideways manner rather than directly.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=141507+0+current/freebsd-
hackers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Fri Sep 25 03:13:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2009 01:13:02 +0000
Subject: [issue6989] Compile error  for Python-2.6.2 on Solaris
In-Reply-To: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
Message-ID: <1253841182.4.0.406962613723.issue6989@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
title: Python-2.6.2 -> Compile error  for Python-2.6.2 on Solaris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6989>
_______________________________________

From report at bugs.python.org  Fri Sep 25 03:18:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2009 01:18:36 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1253841516.07.0.985600525139.issue6722@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Fri Sep 25 03:20:18 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2009 01:20:18 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1253841618.15.0.0327075456167.issue6606@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> skip.montanaro
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Sep 25 03:23:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2009 01:23:41 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1253841821.61.0.71321698613.issue6454@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This seems like a reasonable request.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Fri Sep 25 05:28:00 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 25 Sep 2009 03:28:00 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

When threading.local subclasses are cleared during a reference cycle the 
local's internal key is nulled before the local is deallocated. That's a 
problem because local only deletes its state (ldicts) from threads 
during deallocation, and doesn't do so at all when its key is null.

So leaving ldicts around is one thing, but what's worse is they can be 
recycled by new local objects later -- since ldicts are mapped to 
threadstates by said key, and said key is based on the local's pointer. 
If a new local is malloced at the old one's address it can end up with 
the original's ldicts (depending on which thread it's allocated from).

Attached is a test against trunk showing this. Should we delete the 
ldicts during clear, recreate the key during dealloc, or something else?

----------
components: Interpreter Core
files: derived_local_cycle_dealloc.diff
keywords: patch
messages: 93099
nosy: amaury.forgeotdarc, pjenvey
severity: normal
status: open
title: threading.local subclasses don't cleanup their state and it gets recycled
type: security
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/file14969/derived_local_cycle_dealloc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Fri Sep 25 06:04:55 2009
From: report at bugs.python.org (Ben Bangert)
Date: Fri, 25 Sep 2009 04:04:55 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253851495.1.0.118641973179.issue6990@psf.upfronthosting.co.za>


Changes by Ben Bangert <ben at groovie.org>:


----------
nosy: +bbangert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Fri Sep 25 06:52:24 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 25 Sep 2009 04:52:24 +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: <1253854344.33.0.202565980807.issue5380@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Fri Sep 25 07:29:27 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 05:29:27 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>


New submission from Naoki INADA <songofacandy at gmail.com>:

When stream is codecs.writer object, stream.write(string) does
string.decode() internally and it may cause UnicodeDecodeError.

Then, fallback to utf-8 is not good.
I think good fallback logic is:
* When message is unicode, message.encode(stream.encoding or 'ascii',
'backslashreplace')
* When message is bytes, message.encode('string_escape')

Attached patch contains this logic, refactoring and test.

----------
components: Library (Lib)
files: logging_encode.patch
keywords: patch
messages: 93100
nosy: naoki
severity: normal
status: open
title: logging encoding failes some situation
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14970/logging_encode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 07:41:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 05:41:20 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253857280.04.0.778902231228.issue6988@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Fri Sep 25 07:47:58 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 05:47:58 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253857678.75.0.011693891867.issue6991@psf.upfronthosting.co.za>


Changes by Naoki INADA <songofacandy at gmail.com>:


----------
versions: +Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 07:54:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 05:54:38 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1253858078.68.0.250498994067.issue5127@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5127>
_______________________________________

From report at bugs.python.org  Fri Sep 25 09:32:18 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Sep 2009 07:32:18 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253863938.11.0.557274335942.issue6990@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the excellent test case!
Is seems enough to remove the statement "Py_CLEAR(self->key);" from
local_clear(). self->key is a string which cannot cause cycles (and is
not visited in local_traverse()); now local_dealloc() does its job.

Index: threadmodule.c
===================================================================
--- threadmodule.c	(revision 74229)
+++ threadmodule.c	(working copy)
@@ -239,7 +239,6 @@
 static int
 local_clear(localobject *self)
 {
-	Py_CLEAR(self->key);
 	Py_CLEAR(self->args);
 	Py_CLEAR(self->kw);
 	Py_CLEAR(self->dict);

----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Fri Sep 25 10:39:55 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Sep 2009 08:39:55 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1253867995.21.0.158981652009.issue4434@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does it help if you add the --whole-archive option when linking with the
static library? As explained there:
http://www.lysium.de/blog/index.php?/archives/222-Lost-static-objects-in-static-libraries-with-GNU-linker-ld.html
This way your main program will contain the whole python interpreter,
and all symbols used by time.so &co will be resolved.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________

From report at bugs.python.org  Fri Sep 25 15:19:56 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 13:19:56 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253884796.59.0.419396666408.issue6991@psf.upfronthosting.co.za>


Changes by Naoki INADA <songofacandy at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 16:08:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Sep 2009 14:08:33 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253887713.77.0.636793963653.issue6991@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 16:34:46 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Sep 2009 14:34:46 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253889286.9.0.343518674626.issue6991@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks, but I'm not sure I understand the reasoning.
stream.write(unicode_string) should not do decode() internally, though
of course it would do encode(). Can you explain a little more (with an
illustrative example) what problem you are trying to solve, and attach a
small script which shows the problem? Thanks.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 16:54:41 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 14:54:41 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253890481.48.0.606191373446.issue6991@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

Please see and execute an attached foo.py.

In Python 2.6.2, this cause following error:
>python foo.py
Traceback (most recent call last):
  File "foo.py", line 3, in <module>
    f.write('\xaa')
  File "C:\usr\Python2.6\lib\codecs.py", line 686, in write
    return self.writer.write(data)
  File "C:\usr\Python2.6\lib\codecs.py", line 351, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xaa in position 0:
ordinal not in ran
ge(128)

----------
status: pending -> open
Added file: http://bugs.python.org/file14971/foo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 17:03:14 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 25 Sep 2009 15:03:14 +0000
Subject: [issue6992] multiple authors in setup.by
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

setup.py should allow to specify multiple authors in package description.

----------
assignee: tarek
components: Distutils
messages: 93105
nosy: tarek, techtonik
severity: normal
status: open
title: multiple authors in setup.by

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Fri Sep 25 17:10:41 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Sep 2009 15:10:41 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253891441.05.0.42390735918.issue6991@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There seems to be a problem with your foo.py. In it, you are writing a
byte-string to a stream returned from codecs.open. I don't think this is
correct: you should be writing a Unicode string to that stream, which
will convert to bytes using the stream's encoding, and write those bytes
to file. The following snippet illustrates:

>>> import codecs
>>> f = codecs.open('foo.txt', 'w', encoding='utf-8')
>>> f.write(u'\u76F4\u6A39\u7A32\u7530')
>>> f.close()
>>> f = open('foo.txt', 'r')
>>> f.read()
'\xe7\x9b\xb4\xe6\xa8\xb9\xe7\xa8\xb2\xe7\x94\xb0'

As you can see, the Unicode has been converted using UTF-8.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 17:21:09 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 25 Sep 2009 15:21:09 +0000
Subject: [issue6971] Add the SIO_KEEPALIVE_VALS option to socket.ioctl
In-Reply-To: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
Message-ID: <1253892069.09.0.651148859603.issue6971@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Due to lack of comments, and the straight-forwardness of this change, I 
committed it to the trunk in revision 75054

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6971>
_______________________________________

From report at bugs.python.org  Fri Sep 25 17:52:21 2009
From: report at bugs.python.org (Nikolay Dyankov)
Date: Fri, 25 Sep 2009 15:52:21 +0000
Subject: [issue6993] importing of "time" module is terribly slow
In-Reply-To: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>
Message-ID: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>


New submission from Nikolay Dyankov <ndyankov at gmail.com>:

The behaviour described below is not always reproduced.

The attached test script simply tries to import a couple of dns-python
modules, which in turn import other ones. No code is being executed.
You expect it to exit for less than a second but it does not. Instead,
it hangs when "time" module is being imported (eventually it exits after
a long time).

Attached are stdout log and system call log produced by strace with
timestamps.

I don't know what causes it but I'm getting it on at least two machines
(the second being virtual):


$ cat /etc/fedora-release 
Fedora release 10 (Cambridge)
$ uname -a
Linux kiki 2.6.27.30-170.2.82.fc10.i686.PAE #1 SMP Mon Aug 17 08:24:23
EDT 2009 i686 i686 i386 GNU/Linux
$ python -c "import sys; print sys.version"
2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)]


$ cat /etc/redhat-release 
CentOS release 5.3 (Final)
$ uname -a
Linux proxy.sc.com 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009
i686 i686 i386 GNU/Linux
$ python -c "import sys; print sys.version"
2.4.3 (#1, Jan 21 2009, 01:10:13) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]

I don't think it's related to dns-python(that's why I am posting it
here) but for reference the version used is 1.7.1.


The timestamps in stdout.log and strace.log clearly show the slowdown:

# strace.log
18:18:53 ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfac06b0) = -1 EINVAL
(Invalid argument)
18:18:53 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e4f000
18:18:53 read(6, "F\t\262\276\261s\223I"..., 4096) = 8
18:19:01 read(6, ")v\244\36\v=U\336"..., 4096) = 8
18:19:11 close(6)                       = 0
18:19:11 munmap(0xb7e4f000, 4096)       = 0
18:19:11 gettimeofday({1253891951, 431529}, NULL) = 0

# stdout.log
18:18:53  dns.entropy
18:18:53  time
18:19:11  hashlib
18:19:11  _hashlib

----------
components: Library (Lib)
files: dns-test.tar.gz
messages: 93108
nosy: ndyankov
severity: normal
status: open
title: importing of "time" module is terribly slow
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file14972/dns-test.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6993>
_______________________________________

From report at bugs.python.org  Fri Sep 25 18:00:19 2009
From: report at bugs.python.org (Natalia B. Bidart)
Date: Fri, 25 Sep 2009 16:00:19 +0000
Subject: [issue6994] enumerate dosctring has a typo
In-Reply-To: <1253894419.07.0.333044923608.issue6994@psf.upfronthosting.co.za>
Message-ID: <1253894419.07.0.333044923608.issue6994@psf.upfronthosting.co.za>


New submission from Natalia B. Bidart <nataliabidart at gmail.com>:

Current docstring states:

Return an enumerate object.  iterable must be an other object that
supports iteration.

It should be:

Return an enumerate object. iterable must be another object that
supports iteration.

----------
assignee: georg.brandl
components: Documentation
messages: 93109
nosy: georg.brandl, nessita
severity: normal
status: open
title: enumerate dosctring has a typo
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6994>
_______________________________________

From report at bugs.python.org  Fri Sep 25 18:02:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 16:02:08 +0000
Subject: [issue6994] enumerate dosctring has a typo
In-Reply-To: <1253894419.07.0.333044923608.issue6994@psf.upfronthosting.co.za>
Message-ID: <1253894528.56.0.880558799919.issue6994@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6994>
_______________________________________

From report at bugs.python.org  Fri Sep 25 18:02:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Sep 2009 16:02:52 +0000
Subject: [issue6993] importing of "time" module is terribly slow
In-Reply-To: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>
Message-ID: <1253894572.76.0.57829082443.issue6993@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> "No code is being executed"

Hmm, in dns.entropy module (I found the code there:
http://www.dnspython.com/docs/1.7.1/html/dns.entropy-pysrc.html
) line 89 says "pool = EntropyPool()", and the __init__ function opens
and reads bytes from /dev/random.
This is the cause of the slowdown, as is shown by the strace file.

The time module is innocent here.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6993>
_______________________________________

From report at bugs.python.org  Fri Sep 25 18:16:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 16:16:08 +0000
Subject: [issue6994] enumerate dosctring has a typo
In-Reply-To: <1253894419.07.0.333044923608.issue6994@psf.upfronthosting.co.za>
Message-ID: <1253895368.7.0.882557849892.issue6994@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r75055 (trunk), r75056 (release26-maint), r75057 (py3k) and
r75058 (release31-maint), thanks!

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6994>
_______________________________________

From report at bugs.python.org  Fri Sep 25 18:39:43 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 16:39:43 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253896783.49.0.555227523527.issue6991@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

Another sample.

Traceback (most recent call last):
  File "C:\usr\Python2.6\lib\logging\__init__.py", line 790, in emit
    stream.write(fs % msg.encode("UTF-8"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xaa in position 0:
ordinal not in range(128)

This is because logging.FileHandler uses codecs.open internally.

----------
status: pending -> open
Added file: http://bugs.python.org/file14973/logging_error.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 18:41:11 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Sep 2009 16:41:11 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1253896871.71.0.908365408599.issue6606@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Thanks.  I don't know how to use Reitveld.  What am I supposed to
do with that?

S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:09:51 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Sep 2009 17:09:51 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253898591.95.0.989304139632.issue6991@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Your second example (logging_error.py) fails for the same reason -
you're writing a byte-string to a stream which is expecting Unicode. The
error occurs in logging only it tries encoding as UTF-8 as a last-ditch
attempt - and that only happens because of an earlier exception caused
by you not writing a Unicode string.

In summary: If you open a stream via codecs.open, whether directly or
through the logging module, you are expecting the stream to do encoding
for you. Therefore, you only write Unicode to the stream - never a
byte-string. If you have a byte-string in your application which you
have obtained from somewhere else, convert it to Unicode using whatever
encoding applies to the source. Then, send the resulting Unicode to the
encoding stream (or logger).

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:23:42 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 25 Sep 2009 17:23:42 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253899422.15.0.450481545027.issue6990@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

Great, though I think it still needs to deallocated:

Index: Modules/threadmodule.c
===================================================================
--- Modules/threadmodule.c	(revision 75050)
+++ Modules/threadmodule.c	(working copy)
@@ -244,7 +244,6 @@
 static int
 local_clear(localobject *self)
 {
-	Py_CLEAR(self->key);
 	Py_CLEAR(self->args);
 	Py_CLEAR(self->kw);
 	Py_CLEAR(self->dict);
@@ -266,6 +265,7 @@
 				PyDict_DelItem(tstate->dict, self->key);
 	}
 
+	Py_XDECREF(self->key);
 	local_clear(self);
 	Py_TYPE(self)->tp_free((PyObject*)self);
 }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:26:08 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 25 Sep 2009 17:26:08 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253899568.69.0.645058912274.issue6990@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

Also I've tagged this as a (potential) security issue. E.g. if a web app 
were affected, one user could potentially access another's data.

I actually noticed it in the Beaker sessioning/caching middleware (used by 
Pylons and other web frameworks). Though it only manifested itself as an 
exception in Beaker, others may not be so lucky

So I'd like to apply the ultimate fix all the way down to at least the 2.5 
branch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:41:49 2009
From: report at bugs.python.org (bahaelaila7)
Date: Fri, 25 Sep 2009 17:41:49 +0000
Subject: [issue6995] Python 3.1 interpreter crashes on windows
In-Reply-To: <1253900509.04.0.855711882942.issue6995@psf.upfronthosting.co.za>
Message-ID: <1253900509.04.0.855711882942.issue6995@psf.upfronthosting.co.za>


New submission from bahaelaila7 <bahaelaila7 at gmail.com>:

python3.1 (both amd64 and 32-bit edition) crash whenever i try to start
python.exe.
i've tried that on many windows editions, XP, Vista, Seven,,, for  each,
64 and 32 bits editions , virtually and normally...........always get
the same error, as shown in 
http://img33.imageshack.us/img33/7498/screenshot1za.png

----------
files: Screenshot-1.png
messages: 93117
nosy: bahaelaila7
severity: normal
status: open
title: Python 3.1 interpreter crashes on windows
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14974/Screenshot-1.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6995>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:43:21 2009
From: report at bugs.python.org (Deepak Parashar)
Date: Fri, 25 Sep 2009 17:43:21 +0000
Subject: [issue6996] Python 2.6.2 & 3.1.1 Installer
In-Reply-To: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>
Message-ID: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>


New submission from Deepak Parashar <deepakp at sybase.com>:

Need Python 2.6.2 & 3.1.1 Installer for Windows 64 Bit (for Pentium / 
Intel CPU)

----------
components: Installation, Windows
messages: 93118
nosy: deepakp
severity: normal
status: open
title: Python 2.6.2 & 3.1.1 Installer
type: resource usage
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6996>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:44:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Sep 2009 17:44:59 +0000
Subject: [issue6996] Python 2.6.2 & 3.1.1 Installer
In-Reply-To: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>
Message-ID: <1253900699.17.0.705002866969.issue6996@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Installers (including 64-bit Windows, aka AMD64) are available on
http://python.org/download/.
If your platform isn't supported, please be more specific about it.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6996>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:49:41 2009
From: report at bugs.python.org (Deepak Parashar)
Date: Fri, 25 Sep 2009 17:49:41 +0000
Subject: [issue6996] Python 2.6.2 & 3.1.1 Installer
In-Reply-To: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>
Message-ID: <1253900981.07.0.273412480872.issue6996@psf.upfronthosting.co.za>


Deepak Parashar <deepakp at sybase.com> added the comment:

Actually i was looking forward to install the Python on Xeon CPU based 
Windows 64 BIt Machine , any idea of the link if the installer i can 
download.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6996>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:53:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Sep 2009 17:53:56 +0000
Subject: [issue6996] Python 2.6.2 & 3.1.1 Installer
In-Reply-To: <1253900981.07.0.273412480872.issue6996@psf.upfronthosting.co.za>
Message-ID: <1253901442.5364.150.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually i was looking forward to install the Python on Xeon CPU based 
> Windows 64 BIt Machine , any idea of the link if the installer i can 
> download.

Actually, the AMD64 version should work perfectly on 64-bit Intel CPUs.
(it's also known as x86-64)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6996>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:55:41 2009
From: report at bugs.python.org (Deepak Parashar)
Date: Fri, 25 Sep 2009 17:55:41 +0000
Subject: [issue6996] Python 2.6.2 & 3.1.1 Installer
In-Reply-To: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>
Message-ID: <1253901341.67.0.296279825966.issue6996@psf.upfronthosting.co.za>


Deepak Parashar <deepakp at sybase.com> added the comment:

Thanks , let me give a try , will keep you posted for the status.

Again Thanks ,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6996>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:58:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Sep 2009 17:58:16 +0000
Subject: [issue6995] Python 3.1 interpreter Fatal Error on windows with
	unknown encoding cp720
In-Reply-To: <1253900509.04.0.855711882942.issue6995@psf.upfronthosting.co.za>
Message-ID: <1253901496.22.0.159828388343.issue6995@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of Issue1616979, which has been accepted and applied.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
title: Python 3.1 interpreter crashes on windows -> Python 3.1 interpreter Fatal Error on windows with unknown encoding cp720
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6995>
_______________________________________

From report at bugs.python.org  Fri Sep 25 19:58:43 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 17:58:43 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253901523.33.0.15704211801.issue6991@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

OK, you're right.
But logging is very basic feature and used very wide modules.
"All logging code should use unicode string" is right but difficult.

And logging may be used for debbuging usually. So I think
logging should write log as safe as possible.
When log.error(...) called, no-one wants UnicodeDecodeError
from logging in their log.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 20:15:06 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Sep 2009 18:15:06 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253902506.68.0.769523809411.issue6991@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's not about logging - your first example (foo.py) didn't have any
logging code in it.

The problem is caused only when someone doesn't understand how Unicode
and codecs.open works, and logging can't fix this.

The rule is: If you use a stream without encoding and byte strings under
Python 2.x, you'll be OK - fine if you're using ASCII or Latin-1.
However, users of systems outside this (e.g. CJK or Cyrillic) will not
be covered.

For use anywhere, you really have to work in Unicode internally, decode
stuff on the way in and encode stuff on the way out. That's what the
codecs module is for.

If third-party libraries which you are using don't use Unicode properly,
then they are broken, and logging can't fix that. Any attempt to "paper
over the cracks" will fail sooner or later. It's better to identify the
problem exactly where it occurs: Python's Zen says "Errors should never
pass silently."

I'm closing this issue, as it's not really logging-related. Hope that's OK.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:02:02 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 19:02:02 +0000
Subject: [issue6991] logging encoding failes some situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253905322.93.0.152988813006.issue6991@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

OK, I agree.
Thank you for your answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:04:35 2009
From: report at bugs.python.org (Nikolay Dyankov)
Date: Fri, 25 Sep 2009 19:04:35 +0000
Subject: [issue6993] importing of "time" module is terribly slow
In-Reply-To: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>
Message-ID: <1253905475.88.0.403113098304.issue6993@psf.upfronthosting.co.za>


Nikolay Dyankov <ndyankov at gmail.com> added the comment:

Stupid me :))
I must have really missed that.

Still I don't understand why the read call takes 10 seconds to complete.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6993>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:17:03 2009
From: report at bugs.python.org (Dylan)
Date: Fri, 25 Sep 2009 19:17:03 +0000
Subject: [issue6997] python26 compiled on snow leopard x86_64
In-Reply-To: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>
Message-ID: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>


New submission from Dylan <dmahoney74 at gmail.com>:

Hi guys, 

I consider myself self-taught average geek. after a long time trying
many things to get python2.6.2 to build with macports it fails every
time until i used this specific argument in the work folder below

cd
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2

configure and make as followed (this is what i know works, i know there
is possibly a shorter more proficient way to do this so don't blame me i
just got this thing to compile is all.)

sudo DEFAULT_ARCH=x86_64 MACOSX_DEPLOYMENT_TARGET=10.6 ./configure
--with-universal-archs=64-bit

Please share this among devs at macports Thought I'd mention my success
here first.

- Dylan Mahoney

----------
components: Build
messages: 93128
nosy: monway
severity: normal
status: open
title: python26 compiled on snow leopard x86_64
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6997>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:23:34 2009
From: report at bugs.python.org (Nikolay Dyankov)
Date: Fri, 25 Sep 2009 19:23:34 +0000
Subject: [issue6993] importing of "time" module is terribly slow
In-Reply-To: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>
Message-ID: <1253906614.1.0.353912263762.issue6993@psf.upfronthosting.co.za>


Nikolay Dyankov <ndyankov at gmail.com> added the comment:

OK, I found the reason and it is the very fact of using /dev/random
which would block if there aren't enough random numbers in queue.
Maybe dns-python should be using /dev/urandom instead (though there
might be reasons for not doing so).

The mystery is revealed.
I am closing the bug.
:)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6993>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:28:40 2009
From: report at bugs.python.org (Dylan)
Date: Fri, 25 Sep 2009 19:28:40 +0000
Subject: [issue6997] python26 compiled on snow leopard x86_64
In-Reply-To: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>
Message-ID: <1253906920.91.0.193365418543.issue6997@psf.upfronthosting.co.za>


Dylan <dmahoney74 at gmail.com> added the comment:

oops forgot to mention i realized it was defaulted to /usr/local so i
tried compiling the same configuration except adding --prefix=/opt/local 

built fine

try using

sudo DEFAULT_ARCH=x86_64 MACOSX_DEPLOYMENT_TARGET=10.6 ./configure
--with-universal-archs=64-bit --prefix=/opt/local

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6997>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:33:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Sep 2009 19:33:24 +0000
Subject: [issue6997] python26 compiled on snow leopard x86_64
In-Reply-To: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>
Message-ID: <1253907204.01.0.652754953128.issue6997@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for this.  Fixes to allow Python to build on Snow Leopard have 
already been applied to the svn repository, and will be included in the 
soon-to-appear Python 2.6.3 release.

If you have time, please do check out the svn source and verify that it 
builds for you.  The URL is:

http://svn.python.org/projects/python/branches/release26-maint

Instructions for working with Python svn are at:

http://www.python.org/dev/faq/

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6997>
_______________________________________

From report at bugs.python.org  Fri Sep 25 21:58:00 2009
From: report at bugs.python.org (Michael Markert)
Date: Fri, 25 Sep 2009 19:58:00 +0000
Subject: [issue6998] Bug in Tutorial (introduction.rst)
In-Reply-To: <1253908680.28.0.431854993556.issue6998@psf.upfronthosting.co.za>
Message-ID: <1253908680.28.0.431854993556.issue6998@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

There is a `print` statement in line 225 of introduction.rst instead of
a print function, rendering the snippet buggy in Python3.

----------
assignee: georg.brandl
components: Documentation
messages: 93132
nosy: cofi, georg.brandl
severity: normal
status: open
title: Bug in Tutorial (introduction.rst)
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6998>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:03:40 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 20:03:40 +0000
Subject: [issue6998] Bug in Tutorial (introduction.rst)
In-Reply-To: <1253908680.28.0.431854993556.issue6998@psf.upfronthosting.co.za>
Message-ID: <1253909020.37.0.357171080647.issue6998@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6998>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:05:03 2009
From: report at bugs.python.org (Dylan)
Date: Fri, 25 Sep 2009 20:05:03 +0000
Subject: [issue6997] python26 compiled on snow leopard x86_64
In-Reply-To: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>
Message-ID: <1253909103.19.0.112765487821.issue6997@psf.upfronthosting.co.za>


Dylan <dmahoney74 at gmail.com> added the comment:

Thanks!
compiled cleanly @/opt/local
build is active.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6997>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:07:58 2009
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 25 Sep 2009 20:07:58 +0000
Subject: [issue6999] TypeError in pathfix.py
In-Reply-To: <1253909278.7.0.408125784392.issue6999@psf.upfronthosting.co.za>
Message-ID: <1253909278.7.0.408125784392.issue6999@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

Tools/scripts/pathfix.py crashes with a TypeError:

Traceback (most recent call last):
  File "Tools/scripts/pathfix.py", line 149, in <module>
    main()
  File "Tools/scripts/pathfix.py", line 54, in main
    if recursedown(arg): bad = 1
  File "Tools/scripts/pathfix.py", line 82, in recursedown
    elif ispython(name):
  File "Tools/scripts/pathfix.py", line 64, in ispython
    return ispythonprog.match(name) >= 0
TypeError: unorderable types: NoneType() >= int()

It looks like an easy fix would be to change line 64 from:

    return ispythonprog.match(name) >= 0

to:

    return bool(ispythonprog.match(name))

After making this change, I got another crash, this time due to a
UnicodeDecodeError.  Apparently, the file
(Demo/distutils/test2to3/setup.py) has a character encoded in ISO-8859.
 Since pathfix.py is only concerned with ASCII text in the first line of
a file, it seems that it should probably operate on bytes instead of
unicode strings.

By the way, it's a little odd (but not technically invalid) that the
format string on line 146 is: '#! %s\n'.  I would normally expect to see
no whitespace: '#!%s\n'.

Anyway, I'm attaching a patch that fixes addresses all of the above
issues and which seems to make pathfix.py work for all files in the
Python 3.1.1 source tree.

----------
components: Demos and Tools
files: python-3.1.1-pathfix.patch
keywords: patch
messages: 93134
nosy: amcnabb
severity: normal
status: open
title: TypeError in pathfix.py
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14975/python-3.1.1-pathfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6999>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:14:14 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 25 Sep 2009 20:14:14 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1253909654.58.0.945503997598.issue3890@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'll make this a release blocker, but I agree a test would be useful to
have.  Let's try to get this in for 2.6.3.

----------
nosy: +barry
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:18:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 20:18:49 +0000
Subject: [issue6998] Bug in Tutorial (introduction.rst)
In-Reply-To: <1253908680.28.0.431854993556.issue6998@psf.upfronthosting.co.za>
Message-ID: <1253909929.77.0.899700497572.issue6998@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r75059 (py3k) and r75060 (release31-maint), thanks!

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6998>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:23:09 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 25 Sep 2009 20:23:09 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253910189.06.0.396034532536.issue6990@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:30:32 2009
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 25 Sep 2009 20:30:32 +0000
Subject: [issue6999] TypeError in pathfix.py
In-Reply-To: <1253909278.7.0.408125784392.issue6999@psf.upfronthosting.co.za>
Message-ID: <1253910632.6.0.779090298965.issue6999@psf.upfronthosting.co.za>


Changes by Andrew McNabb <amcnabb at mcnabbs.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6999>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:35:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Sep 2009 20:35:33 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1253517719.13.0.582769224456.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253911145.5364.178.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I tried to implement the new buffer API, but as soon as I add 
> bf_getbuffer/bf_releasebuffer to PyBufferProcs writing an array to a file 
> breaks:

You should take a look at the array module in py3k, it supports the new
buffer API. With a bit of luck, the two relevant functions shouldn't be
too difficult to backport to the trunk.

By the way, to signal that it supports the new buffer API, you must add
Py_TPFLAGS_HAVE_NEWBUFFER to the type flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:37:19 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2009 20:37:19 +0000
Subject: [issue6968] numpy extensions to distutils... are a source of
	improvements for distutils
In-Reply-To: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za>
Message-ID: <1253911039.96.0.610895040906.issue6968@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Closing since the main purpose has been accomplished and there is
otherwise no particular endpoint.

----------
nosy: +tjreedy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6968>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:52:42 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 25 Sep 2009 20:52:42 +0000
Subject: [issue7000] optional second argument of string.keywords not documented
In-Reply-To: <1253911962.13.0.839858916311.issue7000@psf.upfronthosting.co.za>
Message-ID: <1253911962.13.0.839858916311.issue7000@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

string.capwords has an optional second argument, sep, which is not
documented

----------
assignee: georg.brandl
components: Documentation
messages: 93139
nosy: MLModel, georg.brandl
severity: normal
status: open
title: optional second argument of string.keywords not documented
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7000>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:55:46 2009
From: report at bugs.python.org (Philipp Gortan)
Date: Fri, 25 Sep 2009 20:55:46 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1253912146.94.0.949924618424.issue5023@psf.upfronthosting.co.za>


Philipp Gortan <mephinet at gmx.net> added the comment:

I can reproduce this problem with Gentoo Hardened and 
gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.6, ssp-3.4.6-1.0, pie-8.7.10)

when gdb-ing through the datetimemodule.c, and displaying the "tuple"
variable in time_strftime, I can see that the pointer gets modified by
the wrap_strftime call, resulting in Py_DECREF causing the segfault:
before wrap_strftime:
(gdb) x tuple
0xa8938f2c:	0x00000001
after wrap_strftime:
(gdb) x tuple
0x938f2c:	Cannot access memory at address 0x938f2c
thus executing
Py_DECREF(tuple)
results in the segfault.

----------
nosy: +mephinet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Fri Sep 25 22:58:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Sep 2009 20:58:21 +0000
Subject: [issue6999] TypeError in pathfix.py
In-Reply-To: <1253909278.7.0.408125784392.issue6999@psf.upfronthosting.co.za>
Message-ID: <1253912301.78.0.069692521644.issue6999@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Fixed in r75062.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6999>
_______________________________________

From report at bugs.python.org  Fri Sep 25 23:02:51 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Fri, 25 Sep 2009 21:02:51 +0000
Subject: [issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
In-Reply-To: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
Message-ID: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

Among the changes of turtle.py from Python 3.0 to Python 3.1 there were
three bugfixes. Those bugs appear also in the Python 2.6 version of
turtle.py

imho these should be fixed for Python 2.6.3

The appended diffs contain the (backported) fixes of these bugs,
(1) in TurtleScreen.update()
(2) in TurtleScreen.onkey()
(3) in _Screen.__init__ and _Screen.setup

The last one entails the need of adding one line into turtleDemo.py.
This change does not affect the correct working of turtleDemo with the
Python 2.6.2 turtle and demos.

----------
files: turtle_262_263.diff
keywords: patch
messages: 93142
nosy: gregorlingl
severity: normal
status: open
title: turtle.py bug-fixes, backported from 3.1 [issue5923]
versions: Python 2.6
Added file: http://bugs.python.org/file14976/turtle_262_263.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7001>
_______________________________________

From report at bugs.python.org  Fri Sep 25 23:08:09 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Fri, 25 Sep 2009 21:08:09 +0000
Subject: [issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
In-Reply-To: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
Message-ID: <1253912889.0.0.563466090767.issue7001@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

!! This patch should be applied if and only if the corresponding one of
turtle.py is applied !!

----------
nosy: +georg.brandl, loewis
Added file: http://bugs.python.org/file14977/turtleDemo_262_263.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7001>
_______________________________________

From report at bugs.python.org  Fri Sep 25 23:10:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2009 21:10:01 +0000
Subject: [issue7000] optional second argument of string.capwords not documented
In-Reply-To: <1253911962.13.0.839858916311.issue7000@psf.upfronthosting.co.za>
Message-ID: <1253913001.38.0.654880696525.issue7000@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low
resolution:  -> accepted
title: optional second argument of string.keywords not documented -> optional second argument of string.capwords not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7000>
_______________________________________

From report at bugs.python.org  Fri Sep 25 23:15:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Sep 2009 21:15:35 +0000
Subject: [issue6971] Add the SIO_KEEPALIVE_VALS option to socket.ioctl
In-Reply-To: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
Message-ID: <1253913335.99.0.716913126171.issue6971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Will you merge to py3k?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6971>
_______________________________________

From report at bugs.python.org  Sat Sep 26 00:00:31 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Fri, 25 Sep 2009 22:00:31 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1253916031.82.0.236839864215.issue6790@psf.upfronthosting.co.za>


Kirk McDonald <kirklin.mcdonald at gmail.com> added the comment:

And here is a patch removing the array.array.read and .write methods in 
2.7.

----------
Added file: http://bugs.python.org/file14979/issue6790-python2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Fri Sep 25 23:59:32 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Fri, 25 Sep 2009 21:59:32 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1253915972.04.0.0302325087366.issue6790@psf.upfronthosting.co.za>


Kirk McDonald <kirklin.mcdonald at gmail.com> added the comment:

Here is a patch special-casing array.array in httplib.HTTPConnection.send 
in Python 2.6.

----------
keywords: +patch
nosy: +KirkMcDonald
Added file: http://bugs.python.org/file14978/issue6790-python2.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Sat Sep 26 00:25:11 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 25 Sep 2009 22:25:11 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1253917511.85.0.209142408052.issue6243@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Thanks for the bug report and for the fix; 
committed to trunk in rev. 75066.  I modified the patch
slightly to declare the 'knp' variable in the 'else'
block, and both the unctrl()/keyname() sections use the variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Sat Sep 26 00:37:39 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 25 Sep 2009 22:37:39 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253918259.67.0.655504561392.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I added the two functions for the new buffer API. Having an exported 
memory view needs some handling elsewhere, so the array does not change. I 
also added tests for checking that behaviour.

Mainly I copypasted code from py3k which involved redirecting to 
array_resize() instead of doing it manually and doing the checking there.

----------
keywords: +patch
Added file: http://bugs.python.org/file14980/array_new_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat Sep 26 01:11:20 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 25 Sep 2009 23:11:20 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253920280.73.0.462678335524.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

The patch breaks five unit tests from other modules, I'll look into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat Sep 26 02:20:09 2009
From: report at bugs.python.org (Ashish)
Date: Sat, 26 Sep 2009 00:20:09 +0000
Subject: [issue6989] Compile error  for Python-2.6.2 on Solaris
In-Reply-To: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
Message-ID: <1253924409.02.0.705494494544.issue6989@psf.upfronthosting.co.za>


Ashish <pimple9 at gmail.com> added the comment:

Issue seems to be resolved. Please close the issue.

Thanks a lot Mark for your cooperation, support and Guideline.

:-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6989>
_______________________________________

From report at bugs.python.org  Sat Sep 26 02:36:09 2009
From: report at bugs.python.org (Ashish)
Date: Sat, 26 Sep 2009 00:36:09 +0000
Subject: [issue7002] help me to set variables - 64 bit
In-Reply-To: <1253925369.17.0.283500501852.issue7002@psf.upfronthosting.co.za>
Message-ID: <1253925369.17.0.283500501852.issue7002@psf.upfronthosting.co.za>


New submission from Ashish <pimple9 at gmail.com>:

Hello,

I am compiling python 2.6.2 and 3.1.

I tried to compile 64 bit ( ELF 64-bit )python but it gets 32 bit ( ELF
32-bit ).

bash-3.00$ sudo file /usr/local/Python-2.6.2/bin/python
/usr/local/Python-2.6.2/bin/python: ELF 32-bit MSB executable, PowerPC
or cisco 4500, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked
(uses shared libs), not stripped

Will you please help me to set variables and parameters to compile
python for 64 bit on following architect

1. Linux - OS - Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
           Arch - ppc64

2. HP-UX - OS - HP-UX hpi64qa B.11.23 U ia64 (tb)

3. AIX 5 - AIX 5300-07

Thanks 
Ashish

----------
components: Build
messages: 93151
nosy: ashish
severity: normal
status: open
title: help me to set variables - 64 bit
type: compile error
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7002>
_______________________________________

From report at bugs.python.org  Sat Sep 26 03:28:23 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Sep 2009 01:28:23 +0000
Subject: [issue7002] help me to set variables - 64 bit
In-Reply-To: <1253925369.17.0.283500501852.issue7002@psf.upfronthosting.co.za>
Message-ID: <1253928503.43.0.615991097588.issue7002@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You probably need to set the -arch value in your CPPFLAGS. But this is not 
a Python bug. If you need further help please ask at 
comp.lang.python/python-list.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7002>
_______________________________________

From report at bugs.python.org  Sat Sep 26 04:57:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Sep 2009 02:57:40 +0000
Subject: [issue7003] finish documentation of user local paths
In-Reply-To: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>
Message-ID: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This appears at the end of the site documentation:

XXX Update documentation XXX document python -m site ?user-base ?user-site

It should be remedied.

----------
assignee: christian.heimes
messages: 93153
nosy: benjamin.peterson, christian.heimes
severity: normal
status: open
title: finish documentation of user local paths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7003>
_______________________________________

From report at bugs.python.org  Sat Sep 26 04:58:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Sep 2009 02:58:02 +0000
Subject: [issue7003] finish documentation of user local paths
In-Reply-To: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>
Message-ID: <1253933882.37.0.404230898862.issue7003@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7003>
_______________________________________

From report at bugs.python.org  Sat Sep 26 05:32:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Sep 2009 03:32:24 +0000
Subject: [issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
In-Reply-To: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
Message-ID: <1253935944.34.0.833771695753.issue7001@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Gregor, just to make sure I understand, these patches need to be applied
to trunk (2.7) as well as 2.6, correct?

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
priority:  -> normal
stage:  -> commit review
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7001>
_______________________________________

From report at bugs.python.org  Sat Sep 26 11:29:37 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Sep 2009 09:29:37 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253957377.74.0.0869633575494.issue6957@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Explicitly defining CC during the installer build does seem to fix the 
extension build problem, at least for well-behaved extensions.  I 
successfully tested building simplejson (using both easy_install and 
direct setup.py installs) and MySQLdb, both on 10.6 using a fat 
installer built on 10.5 with DEPTARGET=10.3 and 10.4u SDK, test cases 
that previously failed.

I've attached a patch to build-installer.py to support setting CC to 
appropriate values for distutils based on the value of deployment 
target: gcc-4.0 for DEPTARGET in [10.3, 10.4, 10.5], gcc-4.2 for 10.6.

The patch also includes changes to the build process itself to use the 
appropriate gcc, including the recipes for the 3rd-party libs.  This is 
in support of building installers on 10.6 with gcc-4.0 and 10.4u SDKs 
(however, there are still problems with this - see below).

It also includes fixes for two unrelated build problems noted during 
testing: (1) the doc html files are installed in the wrong location in 
the framework (this was fixed in 3.x but not yet backported); and (2) 
the recently changed test for 10.4 or later was off by one (causing 
building to fail on 10.4 systems).  Those fixes should go into 2.6.3 
regardless.

There are some open issues with the patch:

1. Should CXX (the distutils environ value for the c++ compiler) also be 
set? There are multiple paths through configure involving CC and CXX.

2. I chose not to implement a --cc argument to build-installer.py 
figuring it would be safer to hard code the appropriate CC values into 
the script for the time being.

3. While the script as is does not cause regressions for installer 
builds on 10.5 or 10.4 (that is, assuming the remaining builds and tests 
in progress complete normally - I'll update the status when they 
finish), as it stands I am still not able to build "standard" fat 
installers using the 10.4u SDK on 10.6.  There seem to be problems up 
front in configure: a number of build options are coming out differently 
when using 10.4u on 10.6 than on 10.5, presumably causing the cc compile 
errors.  It's not a release-blocker problem, anyway, since the plan is 
to build the installer on 10.5 but we do need to get a better idea 
what's going wrong there.  (Unfortunately, I don't expect to have time 
to investigate this further prior to the 2.6.3 release.)

----------
Added file: http://bugs.python.org/file14981/issue-6957-force-gcc-4.0.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Sat Sep 26 11:49:16 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sat, 26 Sep 2009 09:49:16 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253958556.69.0.190058284745.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I stumbled upon the following function:

static Py_ssize_t
convertbuffer(PyObject *arg, void **p, char **errmsg)
in Python/getargs.c

The first thing the function does is checking if the object implements 
the old buffer api, but also fails if pb->bf_releasebuffer != NULL. So I 
guess it's also making sure the new buffer api is not implemented.

What's the thought behind this? Removing that condition fixes three of 
the failing tests but breaks none.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat Sep 26 13:30:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Sep 2009 11:30:16 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1253920280.73.0.462678335524.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253964828.5509.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch breaks five unit tests from other modules, I'll look into it.

What are those tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat Sep 26 13:37:48 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sat, 26 Sep 2009 11:37:48 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253965068.32.0.112133707727.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

> > The patch breaks five unit tests from other modules, I'll look into
> > it.
> 
> What are those tests?

test_codecs, test_ioctl, test_multiprocessing, test_socket and 
test_struct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat Sep 26 13:48:35 2009
From: report at bugs.python.org (Simon Arlott)
Date: Sat, 26 Sep 2009 11:48:35 +0000
Subject: [issue1175004] Export more libreadline API functions
Message-ID: <1253965715.43.0.531220138307.issue1175004@psf.upfronthosting.co.za>


Simon Arlott <python.simon at arlott.org> added the comment:

Access to rl_reset_line_state (and possibly others in the Redisplay
section) are also required, otherwise it's not possible to recover from
KeyboardInterrupt during raw_input() if readline isn't in the expected
editing mode.

Example:
  1. call raw_input() and use ctrl-R (reverse-i-search)
  2. catch a KeyboardInterrupt
  3. call raw_input() again

The input editing is still in reverse-i-search mode.
This makes it impractical to use raw_input() again after
KeyboardInterrupt because the input buffer may be in an unknown state.
If the history is modified then the search will break and character
input will appear to be ignored.

Note: It may be desirable to stay in this mode and call raw_input()
again, ignoring KeyboardInterrupt entirely (although the prompt is
redisplayed when exiting search mode so that doesn't currently work
cleanly), so it can't just auto-reset on KeyboardInterrupt.

The documentation should explain how to resume after KeyboardInterrupt
safely.

----------
nosy: +lp0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175004>
_______________________________________

From report at bugs.python.org  Sat Sep 26 13:49:01 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sat, 26 Sep 2009 11:49:01 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1253965741.52.0.838191311923.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

You asked "what" not "which" :)

test test_codecs failed -- Traceback (most recent call last):
  File "/Users/jan/src/python-svn/Lib/test/test_codecs.py", line 531, in 
test_array
    codecs.readbuffer_encode(array.array("c", "spam")),
TypeError: must be string or read-only buffer, not array.array


test test_ioctl failed -- Traceback (most recent call last):
  File "/Users/jan/src/python-svn/Lib/test/test_ioctl.py", line 34, in 
test_ioctl_mutate
    r = fcntl.ioctl(tty, termios.TIOCGPGRP, buf, 1)
TypeError: ioctl requires a file or file descriptor, an integer and 
optionally an integer or buffer argument


test test_multiprocessing failed -- Traceback (most recent call last):
  File "/Users/jan/src/python-svn/Lib/test/test_multiprocessing.py", 
line 1269, in test_connection
    self.assertEqual(conn.send_bytes(arr), None)
TypeError: must be string or read-only buffer, not array.array


test test_socket failed -- errors occurred; run in verbose mode for 
details
(have to recheck)


test test_struct failed -- Traceback (most recent call last):
  File "/Users/jan/src/python-svn/Lib/test/test_struct.py", line 468, in 
test_unpack_with_buffer
    value, = struct.unpack('>I', data)
error: unpack requires a string argument of length 4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sat Sep 26 14:37:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Sep 2009 12:37:58 +0000
Subject: [issue7000] optional second argument of string.capwords not documented
In-Reply-To: <1253911962.13.0.839858916311.issue7000@psf.upfronthosting.co.za>
Message-ID: <1253968678.21.0.948349544544.issue7000@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r75070 (trunk), r75071 (release26-maint), r75074 (py3k), r75075
(release31-maint), thanks!

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7000>
_______________________________________

From report at bugs.python.org  Sat Sep 26 18:23:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Sep 2009 16:23:10 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253982190.37.0.38815213701.issue6957@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

> (that is, assuming the remaining builds and tests 
in progress complete normally - I'll update the status when they 
finish)

No regressions noted:
- DEPTARGET=10.3, 2-way i386/ppc, built on 10.5:
     regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386
- DEPTARGET=10.3, 2-way i386/ppc, built on 10.4:
     regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Sun Sep 27 00:36:50 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Sat, 26 Sep 2009 22:36:50 +0000
Subject: [issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
In-Reply-To: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
Message-ID: <1254004610.58.0.411222034084.issue7001@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

These patches need to be applied to 2.6 in order that they appear in
2.6.3. (/python/branches/release26-maint, I think). As far as I see this
is urgent because 2.6.3rc1 is only a few days away.

Eventually (or, if you want at the same time) they need to be applied to
2.7. But there are quite a few amendments more that should be backported
from Python 3.1 to Python 2.7. Moreover, we do not know today, which
bugfixes etc. will go into 3.2 and I think 3.2 should be synchronized
with 2.7. Since 2.7 still seems to be pretty far away, we can defer this
for now and do it later together with the complementing pathes. As
already said, it needs to be done eventually, anyhow. 

Regards,
Gregor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7001>
_______________________________________

From report at bugs.python.org  Sun Sep 27 02:05:00 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 27 Sep 2009 00:05:00 +0000
Subject: [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>


New submission from Jon Parise <jon at indelible.org>:

I've sometimes found it useful to define a convenience macro named
Py_RETURN_BOOL(x) which is essentially:

#define Py_RETURN_BOOL(x) if (x) Py_RETURN_TRUE; else Py_RETURN_FALSE

It's useful for implementing functions which return Boolean values based
on simple conditions.

I think it's readable and doesn't detract from regular program flow,
although it does hide the condition behind a macro, which detracts a bit
from the code's debug-ability.

----------
components: Interpreter Core
files: Py_RETURN_BOOL.patch
keywords: patch
messages: 93164
nosy: jon
severity: normal
status: open
title: Py_RETURN_BOOL() convenience macro
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file14982/Py_RETURN_BOOL.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________

From report at bugs.python.org  Sun Sep 27 02:06:13 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 27 Sep 2009 00:06:13 +0000
Subject: [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254009973.23.0.276827203687.issue7004@psf.upfronthosting.co.za>


Jon Parise <jon at indelible.org> added the comment:

Also attached is a short set of examples of how this macro could be used
in the Python source tree.

----------
Added file: http://bugs.python.org/file14983/Py_RETURN_BOOL.examples.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________

From report at bugs.python.org  Sun Sep 27 02:12:08 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 27 Sep 2009 00:12:08 +0000
Subject: [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254010328.79.0.167441503497.issue7004@psf.upfronthosting.co.za>


Jon Parise <jon at indelible.org> added the comment:

Also attached is a small documentation patch.

----------
Added file: http://bugs.python.org/file14984/Py_RETURN_BOOL.doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________

From report at bugs.python.org  Sun Sep 27 04:46:07 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Sep 2009 02:46:07 +0000
Subject: [issue5460] Python 3.0 grammar is ambiguous with the addition of
	star_expr
In-Reply-To: <1236625214.13.0.530481898617.issue5460@psf.upfronthosting.co.za>
Message-ID: <1254019567.38.0.0157794018185.issue5460@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r75080.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5460>
_______________________________________

From report at bugs.python.org  Sun Sep 27 08:14:05 2009
From: report at bugs.python.org (Mats Kindahl)
Date: Sun, 27 Sep 2009 06:14:05 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>


New submission from Mats Kindahl <mats at sun.com>:

When ConfigParser is used to read in a my.cnf file (MySQL Server
Configuration File), it fails for options that do not have value.

ConfigParser is designed to require a value for each option, but some
systems, such as MySQL option file reader, accepts options without
values. Reading a my.cnf file is almost certain to include options
without values. The server can accept options with values even though
the value is not necessary, but there are some tools that do not allow
values for options that do not require them.

There is an attached patch that optionally will allow options to not
have a value. In order to distinguish options with no value from options
with the empty string, None is assigned to options without values.

The default behavior is to not allow options without values.

----------
components: Library (Lib)
files: cfgparser-1.patch
keywords: patch
messages: 93168
nosy: mkindahl
severity: normal
status: open
title: ConfigParser does not handle options without values
versions: Python 2.6
Added file: http://bugs.python.org/file14985/cfgparser-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Sun Sep 27 09:26:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 27 Sep 2009 07:26:02 +0000
Subject: [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254036362.6.0.831528226249.issue7004@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. What's wrong with writing

   return PyBool_FromLong(x);

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________

From report at bugs.python.org  Sun Sep 27 16:10:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Sep 2009 14:10:49 +0000
Subject: [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254060649.92.0.327036097069.issue7004@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I agree with Martin; PyBool_FromLong is sufficient.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________

From report at bugs.python.org  Sun Sep 27 16:23:55 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Sun, 27 Sep 2009 14:23:55 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>


New submission from Milko Krachounov <python at milko.3mhz.net>:

hasattr(x, '__call__') has been suggested as a replacement for
callable(x) in the documentation and in the warning when running
python2.6 with -3. It is also what 2to3 replaces it with. However, the
two are not equivalent.

1. I can add a __call__ attribute to my object with "obj.__call__ =
lambda x:x". That will not make the object callable, callable() on
Python 2.6 returns False, but hasattr(obj, '__call__') returns True.
2. I can implement a __getattr__ that returns something for every
possible attribute name. Again, this doesn't make the object callable,
nor does callable(obj) in Python 2.6 return True.

I think a closer replacement for "callable(x)" would be "'__call__' in
vars(type(x))".

----------
assignee: georg.brandl
components: 2to3 (2.x to 3.0 conversion tool), Documentation, Interpreter Core
messages: 93171
nosy: georg.brandl, milko.krachounov
severity: normal
status: open
title: The replacement suggested for callable(x) in py3k is not equivalent
type: behavior
versions: Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Sun Sep 27 17:03:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Sep 2009 15:03:35 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1253958556.69.0.190058284745.issue6071@psf.upfronthosting.co.za>
Message-ID: <1254064025.5532.5.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The first thing the function does is checking if the object implements 
> the old buffer api, but also fails if pb->bf_releasebuffer != NULL. So I 
> guess it's also making sure the new buffer api is not implemented.
> 
> What's the thought behind this?

The idea is that if a type implements the bf_releasebuffer function, it
shouldn't be used in a situation where the caller won't try to release
the buffer.

It looks a bit unwarranted though, because a type implementing the old
buffer API should be able to function without the releasing anyway.
Otherwise it wouldn't implement that API at all.

Martin, ISTR you did that addition, would you be opposed to removing the
NULL check on bf_releasebuffer when trying to get a buffer through the
old buffer API?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Sun Sep 27 17:09:52 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Sep 2009 15:09:52 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1254064192.46.0.91667529354.issue1745@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Sun Sep 27 17:18:18 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Sep 2009 15:18:18 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1254064698.48.0.375259497408.issue6748@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I can still reproduce this test failure after applying patch from
r74638. I use Gentoo ~amd64.

----------
nosy: +Arfrever
title: test test_telnetlib failed -> test_debuglevel from test_telnetlib.py fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sun Sep 27 17:58:15 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Sun, 27 Sep 2009 15:58:15 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1254067095.53.0.352372696036.issue6393@psf.upfronthosting.co.za>


Svetoslav Agafonkin <svetlyo at gmail.com> added the comment:

There is an error in r74687 (3.x) and r74688 (3.1) fixes - in the 'else' 
clause there should be 'return result' at the end.

----------
nosy: +slavi
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________

From report at bugs.python.org  Sun Sep 27 17:59:28 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Sep 2009 15:59:28 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254067168.22.0.890289763254.issue7006@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In the PEP3100 [1] there's written, in the "to be removed" list:
  "callable(): just use hasattr(x, '__call__') (?) [2] [done]"
and the note refers to a pdf [2] that instead says:
  "callable(): just call it, already"

If callable() was removed to encourage the EAFP [3] style, replacing "if
callable(x):" with "if hasattr(x, '__call__'):" is just a less-accurate
and less-readable way of doing the same (wrong) thing [4] (also note the
(?) next to the hasattr() expression).

This might be OK for automated tools like 2to3, but not for the doc and
the warning. Humans should probably replace the expression with a
try/except instead of using hasattr().
Even for 2to3 there are better and more accurate solutions though, like
the one proposed by the OP (not really readable) and isinstance(x,
collections.Callable).

(Note: what the OP said is correct for new-style classes, for old-style
classes callable() and hasattr() have the same result).

[1]: http://www.python.org/dev/peps/pep-3100/
[2]: Python Regrets:
http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf
[3]: http://docs.python.org/glossary.html#term-eafp
[4]: http://docs.python.org/glossary.html#term-lbyl

----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Sun Sep 27 18:05:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Sep 2009 16:05:36 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1254067536.83.0.916526512098.issue6713@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed int_decimal_conversion_trunk.patch in r75084.  Thanks, Gawain.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sun Sep 27 18:06:37 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Sun, 27 Sep 2009 16:06:37 +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: <1254067597.28.0.569356248949.issue5931@psf.upfronthosting.co.za>


Thijs Triemstra <lists at collab.nl> added the comment:

Here's a patch that uses platform.python_implementation instead, 
producing:

>>> from wsgiref import simple_server
>>> simple_server.software_version
'WSGIServer/0.1 CPython/2.7a0'
>>> 

This will become relevant when Jython and IronPython start using these 
modules.

----------
keywords: +patch
Added file: http://bugs.python.org/file14986/wsgiref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5931>
_______________________________________

From report at bugs.python.org  Sun Sep 27 18:08:31 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Sun, 27 Sep 2009 16:08:31 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254067711.37.0.583766291027.issue7006@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

My suggestion is not only unreadable, but wrong. It's even less accurate
than hasattr(x, '__call__'), as it doesn't look in all the classes in
the MRO. Using isinstance(x, collections.Callable) should probably be
the correct replacement for 2to3 and situation where checking this is
really needed, as it does look for __call__ in the whole MRO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Sun Sep 27 18:42:50 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Sep 2009 16:42:50 +0000
Subject: [issue4887] environment inspection and manipulation API is buggy,
	inconsistent with "Python philosophy" for wrapping native APIs
In-Reply-To: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za>
Message-ID: <1254069770.26.0.745491452544.issue4887@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4887>
_______________________________________

From report at bugs.python.org  Sun Sep 27 19:08:59 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 27 Sep 2009 17:08:59 +0000
Subject: [issue7007] Tiny inconsistency in the orthography of "url encoded" in
	the doc of urllib.parse
In-Reply-To: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>
Message-ID: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of urllib.parse contains:
    URL encoded
    a ?url-encoded? string
I am not sure what the official usage is, either in Python or more 
generally. Actually, in formal W3C documents the term used is percent-
encoding (with the hyphen, even when used as a noun). I don't expect 
anyone to use "percent-encoding" but maybe, especially as an adjective, 
the phrase in Python documentation should consistently be "url-encoded"?

----------
messages: 93179
nosy: MLModel
severity: normal
status: open
title: Tiny inconsistency in the orthography of "url encoded" in the doc of urllib.parse
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7007>
_______________________________________

From report at bugs.python.org  Sun Sep 27 19:23:26 2009
From: report at bugs.python.org (Nick Devenish)
Date: Sun, 27 Sep 2009 17:23:26 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>


New submission from Nick Devenish <N.e.devenish at sussex.ac.uk>:

str.title() capitalizes the first letter after an apostrophe:

>>> "This isn't right".title()
"This Isn'T Right"

The library function string.capwords, which appears to have exactly the
same responsibility, doesn't exhibit this behavior:

>>> string.capwords("This isn't right")
"This Isn't Right"

Tested on 2.6.2 on Mac OS X

----------
messages: 93180
nosy: nickd
severity: normal
status: open
title: str.title() misbehaves with apostrophes
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Sun Sep 27 21:16:05 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 27 Sep 2009 19:16:05 +0000
Subject: [issue6956] Test creation in unittest.TestProgram should be done in
	one place
In-Reply-To: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za>
Message-ID: <1254078965.65.0.956976814809.issue6956@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 75095.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6956>
_______________________________________

From report at bugs.python.org  Sun Sep 27 22:09:14 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 27 Sep 2009 20:09:14 +0000
Subject: [issue6515]
	http://docs.python.org/dev/library/unittest.html#load-tests-protocol
	doesn't make it clear when load_tests support was introduced
In-Reply-To: <1247929872.52.0.506618276219.issue6515@psf.upfronthosting.co.za>
Message-ID: <1254082154.24.0.251484414014.issue6515@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 75098. Re-open if you think this isn't sufficient.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6515>
_______________________________________

From report at bugs.python.org  Sun Sep 27 22:26:31 2009
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sun, 27 Sep 2009 20:26:31 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1254083191.49.0.543215179256.issue7005@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Sun Sep 27 22:34:11 2009
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sun, 27 Sep 2009 20:34:11 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1254083651.93.0.00506343936476.issue7005@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

The test "value is not None" in line 620 (of the new version) could be
just "value" and get a little more value from less code.

I don't think I've ever run across a sample .ini-style file that used
unspecified values, though it's frequently done in "flat" configuration
files.

Have you come across an existing configuration format that uses the
[section] markers and unspecified values, or is this really a new use-case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Sun Sep 27 22:37:06 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Sun, 27 Sep 2009 20:37:06 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1254083826.43.0.293090041265.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

I'm not actually sure where we go from here. This is my first attempted 
patch to this project, and I was hoping that someone else would be more knowledgeable about the process;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Sun Sep 27 23:11:21 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 27 Sep 2009 21:11:21 +0000
Subject: [issue6971] Add the SIO_KEEPALIVE_VALS option to socket.ioctl
In-Reply-To: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
Message-ID: <1254085881.58.0.967415980991.issue6971@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ported to py3k in revision 75100

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6971>
_______________________________________

From report at bugs.python.org  Sun Sep 27 23:30:12 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 27 Sep 2009 21:30:12 +0000
Subject: [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254087012.71.0.574947556122.issue7004@psf.upfronthosting.co.za>


Jon Parise <jon at indelible.org> added the comment:

I agree, as well.

I didn't consider PyBool_FromLong() because I was expecting to solve the
problem using a macro, but that is clearly not the best approach here
(insignificant function call overhead aside).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________

From report at bugs.python.org  Mon Sep 28 03:23:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2009 01:23:48 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1254101028.27.0.560058478293.issue6606@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thomas, is the patch you uploaded to rietveld the same as the patches
attached to the ticket?  If so, Skip can just ignore the rietveld and
work from the patch files. Rietveld is really more useful for reviews of
longer patches than this one; for patches this size we generally just
use the tracker.

----------
nosy: +r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Mon Sep 28 04:08:05 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Mon, 28 Sep 2009 02:08:05 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1254103685.43.0.565538603515.issue6606@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Got it. Yes, they're the same patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Mon Sep 28 04:13:20 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 28 Sep 2009 02:13:20 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1254104000.27.0.648632124068.issue6606@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Applied to trunk as rev 75102.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Mon Sep 28 05:56:46 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Mon, 28 Sep 2009 03:56:46 +0000
Subject: [issue7009] random.randint docs
In-Reply-To: <1254110206.1.0.201137828001.issue7009@psf.upfronthosting.co.za>
Message-ID: <1254110206.1.0.201137828001.issue7009@psf.upfronthosting.co.za>


New submission from James G. sack (jim) <jgsack at users.sourceforge.net>:

Docs for 2.6.2 (http://docs.python.org/library/random.html?
highlight=random#module-random)
presently say
"""
random.randint(a, b)
Return a random integer N such that a <= N <= b.
"""

It should say
...a <= N < b

I wonder if there are other mistakes there in upper limit docs?

~jim

----------
assignee: georg.brandl
components: Documentation
messages: 93190
nosy: georg.brandl, jgsack
severity: normal
status: open
title: random.randint docs
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7009>
_______________________________________

From report at bugs.python.org  Mon Sep 28 06:02:07 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Mon, 28 Sep 2009 04:02:07 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1254110527.36.0.595074049524.issue6963@psf.upfronthosting.co.za>


Changes by Charles Cazabon <charlesc-python at pyropus.ca>:


Removed file: http://bugs.python.org/file14947/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Mon Sep 28 06:03:26 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Mon, 28 Sep 2009 04:03:26 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1254110606.75.0.152771711124.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Updated patch attached; handles some of the Pool methods that weren't
handled before.  Now includes documentation and unit test additions as well.

----------
Added file: http://bugs.python.org/file14987/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Mon Sep 28 06:37:26 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Sep 2009 04:37:26 +0000
Subject: [issue7009] random.randint docs
In-Reply-To: <1254110206.1.0.201137828001.issue7009@psf.upfronthosting.co.za>
Message-ID: <1254112646.81.0.0188793195425.issue7009@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Not actually a bug. The documentation is correct.
Do, random.randint(0,1) a couple of times and you see 1 appearing.
If still not convinced, look into the random.py see that randint(a, b)
actually does a return self.randrange(a, b+1)

----------
nosy: +senthil.kumaran
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7009>
_______________________________________

From report at bugs.python.org  Mon Sep 28 09:43:58 2009
From: report at bugs.python.org (Per Rosengren)
Date: Mon, 28 Sep 2009 07:43:58 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>


New submission from Per Rosengren <per.rosengren at gmail.com>:

When a floating point value is stored, the actual value stored is 
something at most some small number eps larger or smaller than the 
original value. Python knows this, so if it stores 0.1, and then prints 
the stored value, it rounds off decimals less significant than eps.
For some reason, if it prints a tuple with the same value, it doesn't do 
the rounding properly. This behavior is incorrect, and very annoying for 
instance when printing manually entered constants in tuples.

'''Shows that floats in tuples are not rounded like floats.
>>> print(.1)
0.1
>>> print((.1,))
(0.10000000000000001,)
'''
import doctest
doctest.testmod(verbose=True)

----------
components: Interpreter Core
messages: 93193
nosy: scientist47
severity: normal
status: open
title: Rounding when converting float tuple to str
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 09:54:08 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Sep 2009 07:54:08 +0000
Subject: [issue6992] multiple authors in setup.by
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254124448.26.0.552748697714.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

You can add them in the author field, separated by a space.
It's a free field

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 10:55:20 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 28 Sep 2009 08:55:20 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254128120.64.0.435158960742.issue7010@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

What OS, processor, and Python version are you running this code on?

>From your example, it's Python 3.x. 3.1 has a completely rewritten
float->decimal conversion system, and I get different results.

>>> print(.1)
0.1
>>> print((.1,))
(0.1,)
>>> 

For 2.6 and 3.0, you'll get the old behavior, and this won't change. Are
you really using Python 3.0 (which is marked in the versions)? If so,
switch to 3.1 and see what you get.

----------
nosy: +eric.smith, mark.dickinson
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:12:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Sep 2009 09:12:40 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254129160.39.0.379627479783.issue7010@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is expected (and correct) behaviour for Python 2.x and 3.0.  Note
that the first example calls .1.__str__, while the second calls .1.__repr__.

Python 2.6.2 (r262:71600, Aug 26 2009, 09:40:44)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> str(.1)
'0.1'
>>> repr(.1)
'0.10000000000000001'
>>> str((.1,))
'(0.10000000000000001,)'
>>> tuple(str(x) for x in (.1,))
('0.1',)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:14:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Sep 2009 09:14:34 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254129274.51.0.159483287325.issue7010@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:17:29 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Sep 2009 09:17:29 +0000
Subject: [issue6992] multiple authors in setup.by
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254129449.26.0.317138415043.issue6992@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:19:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Sep 2009 09:19:40 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254129580.08.0.221045117625.issue7010@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And as Eric says, you shouldn't see this behaviour in Python 3.1, since
there str(0.1) == repr(0.1) == '0.1'.  If you are seeing it in 3.1, then
something interesting's happening:  please reopen in that case. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:21:28 2009
From: report at bugs.python.org (Patrick Gerken)
Date: Mon, 28 Sep 2009 09:21:28 +0000
Subject: [issue7011] tarinfo has problems with longlinks
In-Reply-To: <1254129688.2.0.826079779508.issue7011@psf.upfronthosting.co.za>
Message-ID: <1254129688.2.0.826079779508.issue7011@psf.upfronthosting.co.za>


New submission from Patrick Gerken <patrick.gerken at computer.org>:

Sadly, I am unable to debug it enough to be able to provide a thorough
test case. I can provide information of how to reproduce the problem on
request. I have a tar file and a diff to tarfile.py with some pdbs that
only get activated in the middle of the file just before the problematic
data.

Installing an egg fails, and setuptools eats the original error.
The original error is this:
ValueError: 'invalid literal for int(): \xcf\xcf\xdf\xfc\xe9\xcd\xa9\xa9'

That happens in the call to next in the class TarFile. Here we read in a
chunk of filedata, and let TarInfo parse it. But the chunk of data is
actually the beginning of an image in the tar file.
Here is a more thorough report of my pdb findings:

Environment:
I created an egg on linux, which resulted in a tar.gz file. Installing
that egg fails, because the tarfile library has problems reading the tar
file. tar itself can extract the full file without problems.
I have a self compiled python 2.4.6. 

The last file that is apparently read correctly form TarFile.next, is a
LONGLINK, tarinfo.type == 'L'
This type has a method callback in TarInfo.TYPE_METH, which it uses for
returning the real TarInfo object. That goes into proc_gnulong of
tarfile.py.
This proc_gnulong method calls next again, to get the real file info, I
think.
The next buffer that is read out, contains a file name that is exactly
100chars long, and seems to be a directory, because it has a trailing
slash. but its filetype is '0'. 
I suspected the error here, and to cross check, I checked the output of
"tar -tf" on the tar file. I expect tar to return the filenames in the
same order as python reads them in. Before the directory that next seems
to find, there is his parent directory in there. The previous tarinfo
object is exactly about this parent directory. So it looks like, we
actually have a directory entry here.
Enough wild guesses and more observations: The next call of
TarInfo.next() creates a TarInfo object again, here at about line 693,
he checks if the file is a regular file but ends with a slash. If so, he
changes the file type from '0', regular file, to '5', DIRTYPE. He
actually does that with our TarInfo object.

The TarInfo object is created successfully and the next method continues
to run. Then, around line 1650, there is a check, if tarinfo.isreg() or
tarinfo.type not in SUPPORTED_TYPES:...
Here the offset for reading the next TarInfo Buffer is increased by the
size of the actual file size in the tar file. But not for our TarInfo
object, because it is not regular file any longer. If I pad the offset
manually, everything continues to work. But I won't do it this time.
The call to next finishes, and after a while TarInfo.next() is called again.
This time, next tries to read a chunk of data again, but this time, the
chunk of data is an actual file content, it starts with 'GIF89a...',
which makes sense, the directory contains images. Here parsing of the
tar file fails.

----------
components: Library (Lib)
messages: 93198
nosy: do3cc
severity: normal
status: open
title: tarinfo has problems with longlinks
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7011>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:27:36 2009
From: report at bugs.python.org (Mats Kindahl)
Date: Mon, 28 Sep 2009 09:27:36 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1254130056.68.0.122806134444.issue7005@psf.upfronthosting.co.za>


Mats Kindahl <mats at sun.com> added the comment:

I replied to the mail, but I don't know if it is attached to the issue,
so I'll repeat here.

I'll change the "value is not None" to just "value" where I used that idiom.

The style of using options without values is quite common in my.cnf
files used by MySQL programs. For example, in the Debian (Ubuntu)
package I have installed is using several options without values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:32:42 2009
From: report at bugs.python.org (Mats Kindahl)
Date: Mon, 28 Sep 2009 09:32:42 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254083651.93.0.00506343936476.issue7005@psf.upfronthosting.co.za>
Message-ID: <4AC07DC6.9030804@sun.com>


Mats Kindahl <mats at sun.com> added the comment:

Fred L. Drake, Jr. wrote:
> Fred L. Drake, Jr. <fdrake at acm.org> added the comment:
> 
> The test "value is not None" in line 620 (of the new version) could be
> just "value" and get a little more value from less code.

OK.

> 
> I don't think I've ever run across a sample .ini-style file that used
> unspecified values, though it's frequently done in "flat" configuration
> files.
> 
> Have you come across an existing configuration format that uses the
> [section] markers and unspecified values, or is this really a new use-case?

It is very common in my.cnf files for MySQL, and has been so "for ever." For
example, the default my.cnf file that is installed on my Debian (Ubuntu) system
have several options without values (e.g., skip-external-locking, quick, and
quote-names).

Best wishes,
Mats Kindahl

> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7005>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Mon Sep 28 11:49:20 2009
From: report at bugs.python.org (Patrick Gerken)
Date: Mon, 28 Sep 2009 09:49:20 +0000
Subject: [issue7011] tarinfo has problems with longlinks
In-Reply-To: <1254129688.2.0.826079779508.issue7011@psf.upfronthosting.co.za>
Message-ID: <1254131360.48.0.708740597012.issue7011@psf.upfronthosting.co.za>


Patrick Gerken <patrick.gerken at computer.org> added the comment:

doh, I only searched for open bugs. Not for closed.
This ticket is a dublicate of http://bugs.python.org/issue1471427
and fixed in python 2.5.
If somebody has similar problems, here is a quickfix:
I finally was able to reproduce the issue. It only happens when the path
without the filename but the trailing slash is exactly 100 chars long.
Then, because of the trailing slash, tarfile makes this thing a
directory, and if the file itself was not empty, the next read cannot be
parsed as a tar file. Since I am bound to 2.4 I will rename the directories.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7011>
_______________________________________

From report at bugs.python.org  Mon Sep 28 12:31:35 2009
From: report at bugs.python.org (Per Rosengren)
Date: Mon, 28 Sep 2009 10:31:35 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254133895.7.0.768508405558.issue7010@psf.upfronthosting.co.za>


Per Rosengren <per.rosengren at gmail.com> added the comment:

I tried Python 3.1, and it does indeed not have this issue. Thanks for 
swift response!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 12:32:02 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Sep 2009 10:32:02 +0000
Subject: [issue6992] multiple authors in setup.by
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254133922.75.0.14996250582.issue6992@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I want to add their emails also. What to write in author_email in this 
case?

Will such author be parsed by various tools? By PyPi, for example, so that 
everyone get equal credits. I haven't found any remarks about correct 
handling of this field in distutils notes.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 12:56:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Sep 2009 10:56:04 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254135364.25.0.520570905485.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Right, it's not handy for the emails.

PyPI will display the author field, followed by the author_email field.
So everyone will be displayed but not properly.

But no tool is handling the Author and Author-email fields as
multi-value fields.

Maybe we could extend the Metadata by adding a multi-valued
"Contributor" field, that would be composed of a name, and email and a role.

In the Metadata file, things would look like this:

{{{
Contributor: Tarek,tarek at ziade.org,author
Contributor: anatoly techtonik,some at mail.org,maintainer
Contributor: John Doe,some at mail.org
}}}

Where the third field is optional (default: "contributor"). 
and can be set to "author", "maintainer" or "contributor".

On setup.py this would be a 'contributors' list:

{{{
  setup(
     contributors=[
       ['Tarek', 'tarek at ziade.org', 'author'],
       ['anatoly techtonik', 'some at mail.org', 'maintainer'],
       ['John Doe', 'some at mail.org'],
     ]
   )
}}}

Then, 'author' and 'maintainer' would be deprecated, but still filled
by Distutils by choosing some entries out of the contributors list.

this would be added in 2.7, 3.2 and PyPI would have to change accordingly.

----------
resolution: rejected -> 
title: multiple authors in setup.by -> Adding a Contributor field in PEP 314
type:  -> feature request
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 14:26:24 2009
From: report at bugs.python.org (Rohde Fischer)
Date: Mon, 28 Sep 2009 12:26:24 +0000
Subject: [issue7012] Tabs is better than spaces for identation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>


New submission from Rohde Fischer <krdata at gmail.com>:

Although it's probably futile, I'll still give it a try.

I can see in your tutorial that you desire 4 spaces over tabs. I have 
never seen a good argument for spaces (and I've seen a lot), so I'll 
try to convince that tabs is the way (god damn it we don't live in 1980 
any more).

>From the tutorial: "Tabs introduce confusion, and are best left out." - 
only if you're switching in the middle of a document, tabs and spaces 
are equally confusing (I would say they're the opposite, but ok). 
There's no difference on that part.

Then some of the arguments I've heard is that some editors shows tabs 
badly, although true, then most proper editors it's possible to adjust 
that to your personal preference, removing that possibility you are 
removing a nice (although not entirely needed) flexibility.

In a program with 200 lines of code we have roughly 600 extra 
keystrokes with spaces, unless using a proper editor which shows tabs 
nicely.

Tabs use less space, which is usable when uploading and downloading 
code a lot (which you do when using version control).

Posting on forums is a problem with tabs. True, but then you can use 
proper utilities for that, and although I don't use forums for code 
issues I would seriously question the forum if a code-related forum 
didn't convert tabs, and even if it doesn't then I would still use a 
pastebin utility, since it offers all those nice features like syntax 
highlighting and auto conversion of tabs.

4 spaces is prettier than tabs converted to 8 spaces. True but yet 
again most editors can adjust that or actually use 4 spaces per 
default, but if I like 2 spaces I can't do that without introducing 
confusion, so spaces actually introduces more confusion than tabs.

Good editors makes spaces transparent and behave like tabs, true but 
good editors also makes tabs look pretty. But editing manual spaces is 
hell compared to the ugliness of a bad editor, and I prefer usability 
over pretty.

This don't look good with tabs
string = "some multiline whatever string"+
         " and continued"
string = "some multiline whatever string"+
            " and continued"
True, but not unreadable, and if insisting on pretty you can switch to 
tabs for identation spaces for multiline prettyness.

So until I see good arguments for spaces I would really like to see the 
standard switched to tabs, since I see no good reason for claiming 
spaces is better ... actually so see reason to claim otherwise.

----------
components: None
messages: 93205
nosy: rohdef
severity: normal
status: open
title: Tabs is better than spaces for identation
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Mon Sep 28 15:03:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2009 13:03:58 +0000
Subject: [issue7012] Tabs is better than spaces for identation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254143038.02.0.327976228907.issue7012@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python started out using tabs, for some of the reasons you elaborate.
Years of practical experience have shown that using tabs causes pain. 
Our recommendation is not going to change.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Mon Sep 28 15:09:23 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 28 Sep 2009 13:09:23 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1254143363.71.0.162128747953.issue6836@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed the fix to parsetok.c in revision 75103

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6836>
_______________________________________

From report at bugs.python.org  Mon Sep 28 15:13:10 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 28 Sep 2009 13:13:10 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1254143590.8.0.699982982525.issue6836@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed changed debug memory API in revision 75104

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6836>
_______________________________________

From report at bugs.python.org  Mon Sep 28 15:45:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 28 Sep 2009 13:45:30 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1254145530.13.0.136601248391.issue6836@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

merged to py3k in 75105

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6836>
_______________________________________

From report at bugs.python.org  Mon Sep 28 16:19:21 2009
From: report at bugs.python.org (Joseph Tate)
Date: Mon, 28 Sep 2009 14:19:21 +0000
Subject: [issue6606] csv.Sniffer.sniff on data with doublequotes doesn't set
	up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1254147561.13.0.160994408018.issue6606@psf.upfronthosting.co.za>


Joseph Tate <jtate+python at dragonstrider.com> added the comment:

Thank you, Thomas, for the patch, and Skip, for applying it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________

From report at bugs.python.org  Mon Sep 28 16:33:11 2009
From: report at bugs.python.org (David Kirkby)
Date: Mon, 28 Sep 2009 14:33:11 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1254148391.27.0.146340015322.issue1222585@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Just to add, I'd much appreciate if this bug could be squashed. I see
there is a patch, but it is against a 3-year old version, and is not a
small patch. Hence I am reluctant to try to apply it myself. 

It is causing a problem in the Sage project, as I tried to compile Sage
with Sun's compiler on Solaris, rather than gcc.

----------
nosy: +drkirkby
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Sep 28 16:43:48 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Sep 2009 14:43:48 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1254149028.3.0.887573265934.issue1222585@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Mon Sep 28 16:59:29 2009
From: report at bugs.python.org (Marco B)
Date: Mon, 28 Sep 2009 14:59:29 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254149969.96.0.905602362101.issue7008@psf.upfronthosting.co.za>


Marco B <marcusbu at gmail.com> added the comment:

This was already asked some years ago.

http://mail.python.org/pipermail/python-list/2006-April/549340.html

----------
nosy: +markon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 17:45:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2009 15:45:27 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1254152727.0.0.0991243694395.issue6836@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Krisjan, after your commit I'm getting the following when trying to make
python on both trunk and py3k:

Objects/obmalloc.c:1372: error: conflicting types for
'_PyObject_DebugCheckAddress'

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6836>
_______________________________________

From report at bugs.python.org  Mon Sep 28 17:58:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 28 Sep 2009 15:58:48 +0000
Subject: [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1254153528.57.0.764544636367.issue6836@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

visual Studio didn't detect the missing 'const' for the void pointer.  
Fixed now in revision 75016 and revision 75107

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6836>
_______________________________________

From report at bugs.python.org  Mon Sep 28 18:40:31 2009
From: report at bugs.python.org (Andrei Korostelev)
Date: Mon, 28 Sep 2009 16:40:31 +0000
Subject: [issue7013] Httplib read routine is not tolerant to not well-formed
	chunked http responses.
In-Reply-To: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>
Message-ID: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>


New submission from Andrei Korostelev <andrei at korostelev.net>:

HTTPResponse._read_chunked cannot handle "slightly" ill-formed HTTP
response not ended with 0 chunk-size. I did not make an analysis what
type of webservers generate such responses, but one of them is bing.com
(former msn.com).

Example correct chunked http response:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

B
first chunk

A
last chunk

0

Example chunked http rsponse not ended with zero length:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

B
first chunk

A
last chunk


Suggested solution: when an empty line is met where a hexadecimal
chunk-size is expected, treat it as the end of HTTP response. 

--- C:\Python25\Lib\httplib.py.orig	2008-02-12 20:48:24.000000000 +-0200
+++ C:\Python25\Lib\httplib.py.patched	2009-09-28 18:30:33.000000000 +-0200
@@ -542,12 +542,16 @@
         while True:
             if chunk_left is None:
                 line = self.fp.readline()
                 i = line.find(';')
                 if i >= 0:
                     line = line[:i] # strip chunk-extensions
+                # handle ill-formed response not ended with 0 chunk-size
+                line = line.strip()
+                if not line:
+                    break
                 chunk_left = int(line, 16)
                 if chunk_left == 0:
                     break
             if amt is None:
                 value += self._safe_read(chunk_left)
             elif amt < chunk_left:

Attached patches for Python-2.5, Python-2.6 and Python-3.1.

----------
components: Library (Lib)
files: httplib.python-2.5.diff
keywords: patch
messages: 93215
nosy: Andrei Korostelev
severity: normal
status: open
title: Httplib read routine is not tolerant to not well-formed chunked http responses.
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14988/httplib.python-2.5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7013>
_______________________________________

From report at bugs.python.org  Mon Sep 28 18:45:56 2009
From: report at bugs.python.org (Andrei Korostelev)
Date: Mon, 28 Sep 2009 16:45:56 +0000
Subject: [issue7013] Httplib read routine is not tolerant to not well-formed
	chunked http responses.
In-Reply-To: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>
Message-ID: <1254156356.01.0.136896424712.issue7013@psf.upfronthosting.co.za>


Andrei Korostelev <andrei at korostelev.net> added the comment:

Patch for Python-2.6

----------
Added file: http://bugs.python.org/file14989/httplib.python-2.6.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7013>
_______________________________________

From report at bugs.python.org  Mon Sep 28 18:49:43 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Sep 2009 16:49:43 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254156583.95.0.879110021171.issue6992@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Too complicated. I think any who significantly contributed to some 
package is an author. Maintainer is the one who does the goodness of 
making this package available to other systems through PyPi.

{{{
authors = [
  'Anatoli <email at here>',
  'Tarek <email at here>'
]
}}}

<email at xxx> part is optional. Simple, intuitive, readable and easy 
enough to parse. The same for maintainers. There is no need for 
complicated role management - let's leave this for extensions. At the 
moment the real problem is to give attribution to several people at once 
in Pythonic way. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 18:51:00 2009
From: report at bugs.python.org (Andrei Korostelev)
Date: Mon, 28 Sep 2009 16:51:00 +0000
Subject: [issue7013] Httplib read routine is not tolerant to not well-formed
	chunked http responses.
In-Reply-To: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>
Message-ID: <1254156660.16.0.733291366077.issue7013@psf.upfronthosting.co.za>


Andrei Korostelev <andrei at korostelev.net> added the comment:

Added patch for python-3.1.1

----------
Added file: http://bugs.python.org/file14990/httplib.python-3.1.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7013>
_______________________________________

From report at bugs.python.org  Mon Sep 28 19:02:07 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Sep 2009 17:02:07 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254157327.22.0.512295495999.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Notice that there's another issue: maintainer is not written in the
Metadata if author is provided.

Plus, PyPI has its own role system: owner+maintainer, that has nothing 
to do with the package Metadata (it's just who registered the package
and who was granted some access)

So at the end, if we don't manage roles at the Metadata level, 
I don't see any good reason not to have one single 'authors' option
with a list of authors.

Having the mail like you've described is a good idea too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 19:51:18 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Mon, 28 Sep 2009 17:51:18 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254160278.82.0.100931518496.issue7008@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

The string module, however, fails to properly capitalize anything in quotes:

>>> string.capwords("i pity the 'foo'.")
"I Pity The 'foo'."

The string module could be easily made to work like the object. The
object could be made to work more like the module, only capitalizing
things after a space and the start of the string, but I'm not really
sure that it's any better. (The s.istitle() should also be updated if
s.title() is changed.) The inconsistency is pretty nasty, though, and
the documentation should probably be more specific about what's going on.

----------
nosy: +twb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 20:07:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Sep 2009 18:07:27 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254161247.4.0.678881747983.issue6790@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

These methods don't even produce a DeprecationWarning in current 2.6, I
don't think it's ok to remove them.
As for the special casing patch, it would be better with a test.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Mon Sep 28 20:14:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 18:14:08 +0000
Subject: [issue7010] Rounding when converting float tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254161648.81.0.240027644246.issue7010@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

You're seeing the difference between str(.1) and repr(.1).  When
printing the tuple, you're getting the str of the tuple but just the
repr of its contents ('%.17g').   When printing the number directly,
you're just getting the str of the number which is rounded to fewer
decimal places for display ('%.12g').  

This is easily seen with a number like pi:

>>> from math import *
>>> print(pi)
3.14159265359
>>> print((pi,))
(3.141592653589793,)
>>> repr(pi)
'3.141592653589793'
>>> str(pi)
'3.14159265359'

In Py3.1, the repr computation was changed to show the shortest string
the where float(x)==x.  In the case of .1, the repr and str value happen
to be the same (that is why Eric sees no difference in 3.1).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________

From report at bugs.python.org  Mon Sep 28 20:29:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 18:29:31 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254162571.41.0.99280641515.issue7008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree with the OP that str.title should be made smarter.  As it
stands, it is a likely bug factory that would pass unittests, then
generate unpleasant results with real user inputs.

Extending on Thomas's comment, I think string.capwords() needs to be
deprecated and eliminated.  It is an egregious hack that has unfortunate
effects such as dropping runs for repeated spaces and incorrectly
handling strings in quotes.  

As it stands, we have two methods that both don't quite do what we would
really want in a title casing method (correct handling of apostrophe's
and quotation marks, keeping the string length unchanged, and only
changing desired letters from lower to uppercase with no other
side-effects).

----------
nosy: +rhettinger
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 20:42:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Sep 2009 18:42:53 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1254163373.1.0.495139106436.issue6990@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The latest patch + tests looks ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Mon Sep 28 20:58:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2009 18:58:06 +0000
Subject: [issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
In-Reply-To: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
Message-ID: <1254164286.74.0.240617997261.issue7001@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to trunk in r75115, and 2.6 in r75116.  As far as I know there
are no tests for this module other than the doctests in the
documentation.  Those at least run without errors after the patches.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7001>
_______________________________________

From report at bugs.python.org  Mon Sep 28 21:02:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2009 19:02:06 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254164526.64.0.751187982607.issue7008@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe capwords was supposed to be removed in 3.0, but this did not
happen.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 21:05:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 19:05:21 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254164721.93.0.907569920049.issue7008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If you can find a link to the discussion for removing capwords, we can
go ahead and deprecate it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 21:08:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 19:08:20 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254164900.79.0.552945764764.issue7008@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/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 21:24:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Sep 2009 19:24:49 +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: <1254165889.4.0.775477808221.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Gamma function added in r75117 (trunk), r75119 (py3k).
I'm working on lgamma.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Sep 28 21:27:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2009 19:27:19 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254166039.44.0.0449466356561.issue7008@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't been able to find any discussion of deprecating capwords other
than a mention in this thread:

http://mail.python.org/pipermail/python-3000/2007-April/006642.html

Later in the thread Barry says he is neutral on removing capwords, and
it is not mentioned further.

I think Ezio found some other information somewhere.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 22:01:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 28 Sep 2009 20:01:46 +0000
Subject: [issue7012] Tabs is better than spaces for identation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <4AC11626.5070701@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Then some of the arguments I've heard is that some editors shows tabs 
> badly, although true, then most proper editors it's possible to adjust 
> that to your personal preference

That is no option for Python. In Python, it is part of the LANGUAGE
SYNTAX that a tab is 8 columns. Changing that may change the very
meaning of a Python program (i.e. an editor configured to four column
tabs may render a program to MEAN something different than when
formatted to eight column tabs).

So a tab is 8 columns, period.

> In a program with 200 lines of code we have roughly 600 extra 
> keystrokes with spaces, unless using a proper editor which shows tabs 
> nicely.

I think you should get a different editor then. I press tab in my
editor and still get four spaces.

> Tabs use less space, which is usable when uploading and downloading 
> code a lot (which you do when using version control).

That's negligible, compared to the rest of the file.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Mon Sep 28 22:34:00 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Sep 2009 20:34:00 +0000
Subject: [issue7012] Tabs is better than spaces for identation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254170040.96.0.637891544835.issue7012@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Wow. You (rohdef) really do sound like you are a time capsule from the 
eighties. Tabs would save keystrokes and bandwidth, and are not 
confusing? The keystrokes argument is wrong for most editors; the 
bandwidth argument doesn't matter due to disk size, network speed, and 
compression; and the confusion is absolutely real. Pretty much every 
time I volunteer to help out a group of Python newbies there is at least 
one baffling problem due to tabs/spaces. There are hundreds of different 
text editors that people use on a regular basis to edit Python source 
code. They all display spaces the same way; not so for tabs. Most of 
them have configurable behavior for tabs, and most of the time the users 
are not aware of even the existence of those settings, let alone what 
setting is currently being used.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Mon Sep 28 22:42:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Sep 2009 20:42:36 +0000
Subject: [issue7012] Tabs is better than spaces for indentation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254170556.06.0.116324343697.issue7012@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: Tabs is better than spaces for identation -> Tabs is better than spaces for indentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Mon Sep 28 22:45:35 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Mon, 28 Sep 2009 20:45:35 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254170735.05.0.327941664605.issue7008@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

If "correct handling of apostrophe's and quotation marks, keeping the
string length unchanged, and only changing desired letters from lower to
uppercase with no other side-effects" is the criterion we want, then
what I suggested (toupper() the first character, and any character that
follows a space or punctuation character) should work. (Unless I'm
missing something.) Do we want to tolower() all other characters, like
the interpreter does now?

I can make a test and patch for this if this is what we decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 22:53:00 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 28 Sep 2009 20:53:00 +0000
Subject: [issue7014] Logging incompatible with IronPython
In-Reply-To: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>
Message-ID: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Logging is incompatible with IronPython 2.6. 

See: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24714

The core of the issue is that logging assumes that if sys._getframe is
not defined then frames can still be accessed through exceptions.

For IronPython this isn't true - *if* sys._getframe is not available in
IronPython (frames have to be specifically enabled) then frames are not
available at all.

Are there any platforms now where sys._getframe will be unavailable but
frames are still available? I don't think this applies to Jython where
frames are always available in recent versions (2.5 - and this would
only be backported to 2.6).

----------
assignee: michael.foord
components: Library (Lib)
messages: 93233
nosy: michael.foord, vinay.sajip
severity: normal
stage: needs patch
status: open
title: Logging incompatible with IronPython
type: crash
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7014>
_______________________________________

From report at bugs.python.org  Mon Sep 28 23:00:42 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Sep 2009 21:00:42 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254171642.43.0.452917221767.issue6992@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Having single `authors` field is enough, indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Sep 28 23:02:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 21:02:24 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254171744.57.0.855191107022.issue7008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm still researching what other languages do.  MS-Excel matches what
Python currently does.  Django uses the python version and then fixes-up
apostrophe errors:  
    title=lambda value: re.sub("([a-z])'([A-Z])", lambda m:
m.group(0).lower(), value.title()).   

It would also be nice to handle hyphenates like "xray" --> "X-ray".   

Am thinking that it would be nice if the user could pass-in an optional
argument to list all desired characters to prevent transitions (such as
apostrophes and hyphens).

A broader solution would be to replace string.capwords() with a more
sophisticated set of rules that generally match what people are really
trying to accomplish with title casing:  

   http://aitech.ac.jp/~ckelly/midi/help/caps.html

   http://search.cpan.org/dist/Text-Capitalize/Capitalize.pm

   "Headline Style" in the Chicago Manual of Style or 
   Associate Pressd Stylebook:  
  
http://grammar.about.com/b/2008/04/11/rules-for-capitalizing-the-words-in-a-title.htm

Any such attempt at a broad solution needs to provide ways for users to
modify the list of exception words and options for quoted text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 23:39:10 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 21:39:10 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254173950.6.0.801213864845.issue7008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thomas, if you write-up an initial patch, aim for the most conservative
version that leaves all of the behavior unchanged except for embedded
single apostrophes (to handle contractions and possessives).  That will
assure that we don't muck-up any existing uses for title case:


   i'm      I'm
   you're   You're
   he's     He's
   david's  David's
   'bad'    'Bad'
   f''t     f''t
   'x       'x

Given letters-apostrophe-letter, capitalize only the first letter and
lowercase the rest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Mon Sep 28 23:41:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Sep 2009 21:41:02 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254174062.81.0.0444365825467.issue7008@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We shouldn't change the current default behaviour, people are probably
relying on it.

Besides, doing the right thing is both (natural) language-dependent and
context-dependent. It would be (very) hard to come with an
implementation catering to all needs. Perhaps a dedicated typography
module, but str.title() is certainly not the answer.

However, adding an optional argument to str.title() so as to change the
list of recognized separators could be an useful addition for those
people who aren't too perfectionist about the result.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 00:21:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 22:21:36 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254176496.63.0.916247854708.issue7008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido, do you have an opinion on whether to have str.title() handle
embedded apostrophes, "you're" --> "You're" instead of "You'Re"?

IMO, the problem comes-up often enough that people are looking for
workarounds (i.e. string.capwords() was a failed hack created to handle
the problem and django.titlecase() is a successful attempt at a workaround).

I'm not worried about Antoines's comment that we can't change anything
ever.  I am concerned about his point (mentioned on IRC) that there are
no context free solutions (the absolute right answer is hard).  While
the change would seem to always be helpful in an English context, in
French the proper title casing of "l'argent" is "L'Argent".  Then again,
there are cases in French that don't work under either method (i.e.
title casing Amaury Forgeot d'Arc ends-up capitalizing the D no matter
what we do).

Options:

1. Leave everything the same (rejecting requests for apostrophe handling
and forever live with the likes of You'Re).

2. Handle embedded single apostrophes, fixing most cases in English, and
wreaking havoc on the French (who are going to be ill-served under any
scenario).

3. Add an optional argument to str.title() with a list of characters
that will not trigger a transition.  This lets people add apostrophes
and hyphens and other characters of interest.  Hyphens are hard because
cases like mother-in-law should properly be converted to Mother-in_Law
and hyphens get used in many odd ways.

4. Add a new string method for handling title case with embedded
apostrophes but leaving the old version unchanged.

My order of preferences is 2,4,3,1.

----------
assignee: rhettinger -> gvanrossum
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 00:32:57 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Sep 2009 22:32:57 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254177177.07.0.359502040103.issue7008@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I think Ezio found some other information somewhere.

While I was fixing #7000 I found that the tests for capwords had been
removed in r54854 but since the function was already there I added them
back in r75072.
The commit message of r54854 says "Also remove all calls to functions in
the string module (except maketrans)". I'm adding Neal to the nosy list,
maybe he remembers if maketrans really was the only function that was
supposed to survive.

In #6412 other problems of .title() are discussed, and there are also a
couple of links to Technical Reports of the Unicode Consortium about
casing algorithms and similar issues (I didn't have time to read them
yet though).

----------
nosy: +nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 00:33:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Sep 2009 22:33:13 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254176496.63.0.916247854708.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254177407.4663.50.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> While
> the change would seem to always be helpful in an English context, in
> French the proper title casing of "l'argent" is "L'Argent".

Well I think even in English it doesn't work right.
For example someone named O'Brien would end up as "O'brien".

My point is that capitalization is both language-sensitive and
context-sensitive, and it's a hard problem for a computer to solve.
Since str.title() can only be a very crude approximation of the right
thing, there's no good reason to break backwards compatibility, IMO.

> 1. Leave everything the same (rejecting requests for apostrophe handling
> and forever live with the likes of You'Re).
> 
> 2. Handle embedded single apostrophes, fixing most cases in English, and
> wreaking havoc on the French (who are going to be ill-served under any
> scenario).
> 
> 3. Add an optional argument to str.title() with a list of characters
> that will not trigger a transition.  This lets people add apostrophes
> and hyphens and other characters of interest.  Hyphens are hard because
> cases like mother-in-law should properly be converted to Mother-in_Law
> and hyphens get used in many odd ways.
> 
> 4. Add a new string method for handling title case with embedded
> apostrophes but leaving the old version unchanged.
> 
> My order of preferences is 2,4,3,1.

I really think the only reasonable options are 3 and 1.
2 breaks compatibility with no real benefit.
4 is too specific a variation (especially in the unicode case, where you
might want to take into account the different variants of apostrophes
and other characters), and adding a new method for such a subtle
difference is not warranted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 00:54:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Sep 2009 22:54:02 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254178442.98.0.895727904915.issue7008@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, we might want to mention in the documentation that the
title() method only gives imperfect results when trying to titlecase
natural language. So that people don't get fooled thinking things are
simple :-) What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:02:53 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Sep 2009 23:02:53 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254178973.99.0.0865778223053.issue7008@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Raymond, please refrain from emotional terms like "bug factory".

I have nothing to say about whether string.capwords() should be removed, 
but I want to note that it does a split on whitespace and then rejoins 
using a single space, so that string.capwords('A  B\tC\r\nD') returns 'A 
B C D'.

The title() method exists primarily because the Unicode standard has a 
definition of "title case".  I wouldn't want to change its default 
behavior because there is no reasonable behavior that isn't locale-
dependent, and Unicode methods shouldn't depend on locale; and even then 
it won't be perfect, as the O'Brien example shows.

Also note that .title() matches .istitle() in the sense that 
x.title().istitle() is supposed to be true (except in end cases like a 
string containing no letters).

I worry that providing an API that adds a way to specify a set of 
characters to be treated as letters (for the purpose of deciding where 
words start) will just make the bugs in apps harder to find because the 
examples are rarer (like "l'Aperitif" or "O'Brien" -- or "RSVP" for that 
matter).  With the current behavior at least app authors will easily 
notice the problem, decide whether it matters to them, and implement 
their own algorithm if they do.  And they are free to be as elaborate or 
simplistic as they care.

What's a realistic use case for .title() anyway?

(Proposal: close as won't fix.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:03:52 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Sep 2009 23:03:52 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254179032.33.0.825180984241.issue7008@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

A doc fix sounds like a great idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:03:59 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Sep 2009 23:03:59 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254179039.79.0.769314173109.issue7008@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:13:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Sep 2009 23:13:00 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254179580.72.0.189053953734.issue7008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I will add a comment to the docs.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:19:31 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Mon, 28 Sep 2009 23:19:31 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254179971.71.0.0373385611505.issue6790@psf.upfronthosting.co.za>


Kirk McDonald <kirklin.mcdonald at gmail.com> added the comment:

I have updated the patch with a unittest for httplib.HTTPConnection.send.

----------
Added file: http://bugs.python.org/file14991/issue6790-python2.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:19:41 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Mon, 28 Sep 2009 23:19:41 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254179981.72.0.750966643231.issue6790@psf.upfronthosting.co.za>


Changes by Kirk McDonald <kirklin.mcdonald at gmail.com>:


Removed file: http://bugs.python.org/file14978/issue6790-python2.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:34:05 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 28 Sep 2009 23:34:05 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1254180845.19.0.546214777341.issue6729@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Ok, apparently the lines that define c_size_t are these:

if sizeof(c_uint) == sizeof(c_void_p):
    c_size_t = c_uint
elif sizeof(c_ulong) == sizeof(c_void_p):
    c_size_t = c_ulong
elif sizeof(c_ulonglong) == sizeof(c_void_p):
    c_size_t = c_ulonglong

(side remark: wouldn't a simple c_size_t = c_void_p do exactly the same
as the above and be much clearer?) 

Unfortunately I have no real idea how to come up with something similar
for ssize_t, since there is no predefined object that is of type ssize_t
(as c_void_p is for type size_t). Any ideas what to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:54:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Sep 2009 23:54:23 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254182063.6.0.927645870286.issue6790@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why do you need to give a non-empty body to the FakeSocket? 

Other than that, looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 01:59:20 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Mon, 28 Sep 2009 23:59:20 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254182360.43.0.77087107503.issue6790@psf.upfronthosting.co.za>


Kirk McDonald <kirklin.mcdonald at gmail.com> added the comment:

Oh, I suppose I don't. I had simply copy and pasted those four lines from 
the previous method. That line could easily be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 02:19:59 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 00:19:59 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254183599.38.0.167898049427.issue6972@psf.upfronthosting.co.za>


Changes by Thomas W. Barr <twb at rice.edu>:


----------
nosy: +twb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 02:24:40 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Tue, 29 Sep 2009 00:24:40 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254183880.77.0.00598826511746.issue6790@psf.upfronthosting.co.za>


Kirk McDonald <kirklin.mcdonald at gmail.com> added the comment:

Remove unused 'body'.

----------
Added file: http://bugs.python.org/file14992/issue6790-python2.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 02:25:16 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Tue, 29 Sep 2009 00:25:16 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254183916.35.0.656497625383.issue6790@psf.upfronthosting.co.za>


Changes by Kirk McDonald <kirklin.mcdonald at gmail.com>:


Removed file: http://bugs.python.org/file14991/issue6790-python2.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 05:44:51 2009
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 29 Sep 2009 03:44:51 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254195891.93.0.559777088396.issue7008@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

I don't recall anything specifically wrt removing capwords.  Most likely
it was something that struck me as not widely used or really
necessary--a good candidate to be removed.  Applications could then
write the fucntion however they chose which would avoid the problem of
Python needing to figure out if it should be Isn'T or Isn't and all the
other variations mentioned here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 06:19:38 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 04:19:38 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254197978.15.0.524603116081.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Do people have an opinion as to whether this should be fixed with a 
docfix, fixed as default (with option to allow path traversal) or fixed as 
a non-default option? The same issue exists in ZipFile.extract, but in 
that case you're presumably passing a path you've already vetted.

Either way, I'll write a test case for it tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 07:32:07 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 29 Sep 2009 05:32:07 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1254202327.59.0.716639627195.issue6990@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

applied in r75123-r75127, including a backport to release25-maint

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Tue Sep 29 08:34:04 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Sep 2009 06:34:04 +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: <1254206044.73.0.0983249024889.issue3366@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve at pearwood.info>:


----------
nosy: +stevenjd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Tue Sep 29 08:38:10 2009
From: report at bugs.python.org (Rishikesh K Rajak)
Date: Tue, 29 Sep 2009 06:38:10 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>


New submission from Rishikesh K Rajak <risrajak at linux.vnet.ibm.com>:

[root@ ~]# python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57) 
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help()

Welcome to Python 2.6!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules spam

Here is a list of matching modules.  Enter any module name to get more help.


** (.:18352): WARNING **: Trying to register gtype 'WnckWindowState' as
flags when in fact it is of type 'GEnum'

** (.:18352): WARNING **: Trying to register gtype 'WnckWindowActions'
as flags when in fact it is of type 'GEnum'

** (.:18352): WARNING **: Trying to register gtype
'WnckWindowMoveResizeMask' as flags when in fact it is of type 'GEnum'
Adding pauses to default speech formatting strings.
Adding pauses to Gecko speech formatting strings.
Adding pauses to soffice speech formatting strings.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site.py", line 433, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib64/python2.6/pydoc.py", line 1720, in __call__
    self.interact()
  File "/usr/lib64/python2.6/pydoc.py", line 1738, in interact
    self.help(request)
  File "/usr/lib64/python2.6/pydoc.py", line 1757, in help
    self.listmodules(split(request)[1])
  File "/usr/lib64/python2.6/pydoc.py", line 1862, in listmodules
    apropos(key)
  File "/usr/lib64/python2.6/pydoc.py", line 1962, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib64/python2.6/pydoc.py", line 1927, in run
    for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
  File "/usr/lib64/python2.6/pkgutil.py", line 110, in walk_packages
    __import__(name)
  File "/usr/lib/python2.6/site-packages/gdb/__init__.py", line 19, in
<module>
    import gdb.command.require
  File "/usr/lib/python2.6/site-packages/gdb/command/require.py", line
21, in <module>
    class RequireCommand (gdb.Command):
AttributeError: 'module' object has no attribute 'Command'
>>>

----------
assignee: georg.brandl
components: Documentation
messages: 93253
nosy: georg.brandl, rishikesh
severity: normal
status: open
title: Getting call trace while executing "modules spam" at help prompt
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Tue Sep 29 08:40:34 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 29 Sep 2009 06:40:34 +0000
Subject: [issue7014] Logging incompatible with IronPython
In-Reply-To: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>
Message-ID: <1254206434.69.0.975002161574.issue7014@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7014>
_______________________________________

From report at bugs.python.org  Tue Sep 29 08:57:14 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Sep 2009 06:57:14 +0000
Subject: [issue7016] .pyc files are set executable if the .py file is too
In-Reply-To: <1254207434.5.0.560245182019.issue7016@psf.upfronthosting.co.za>
Message-ID: <1254207434.5.0.560245182019.issue7016@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

In Python 2.6, .pyc files inherit the executable bit from their .py 
file. This can lead to strangeness:

$ echo pass > test.py
$ chmod u+x test.py
$ python2.6 -c "import test"
$ ls -l test.pyc
-rwxrw-r-- 1 steve steve 94 2009-09-29 16:54 test.pyc
$ ./test.pyc
: command not found ??

----------
components: Interpreter Core
messages: 93254
nosy: stevenjd
severity: normal
status: open
title: .pyc files are set executable if the .py file is too
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7016>
_______________________________________

From report at bugs.python.org  Tue Sep 29 09:07:30 2009
From: report at bugs.python.org (Chris Adamson)
Date: Tue, 29 Sep 2009 07:07:30 +0000
Subject: [issue7017] os.listdir behaviour
In-Reply-To: <1254208050.64.0.613024688273.issue7017@psf.upfronthosting.co.za>
Message-ID: <1254208050.64.0.613024688273.issue7017@psf.upfronthosting.co.za>


New submission from Chris Adamson <cadamson at internode.on.net>:

When I iterate through a list created using os.listdir it seems to grow
as I create files in that directory. I want a static copy of the list of
files in the directory prior to me writing new files into it.

Here is my code:

fileList = os.listdir(temporaryDirectory)

for curFile in fileList:
   # print the file list to see if it is indeed growing
   print FileList
   fp = file(os.path.join(temporaryDirectory, "." + curFile), 'w')
   # write stuff
   fp.close()

Here is the output:

['a', 'b', 'c']
['a', 'b', 'c', '.a']
['a', 'b', 'c', '.a', '.b']
['a', 'b', 'c', '.a', '.b', '.c']

So the list is growing and eventually curFile iterates through the list
of files that were created. This behaviour was unwanted in my case and I
couldn't find any documentation about this.

----------
components: None
messages: 93255
nosy: bigaddo
severity: normal
status: open
title: os.listdir behaviour
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7017>
_______________________________________

From report at bugs.python.org  Tue Sep 29 09:19:26 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 29 Sep 2009 07:19:26 +0000
Subject: [issue7014] Logging incompatible with IronPython
In-Reply-To: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>
Message-ID: <1254208766.4.0.795720963591.issue7014@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and release26-maint. Please verify.

Note - the problem is not just to do with availability of sys._getframe
in Python - it's actually because sys.exc_traceback.tb_frame.f_back is
None (even though sys.exc_traceback.tb_frame is a frame object) when
-X:Frames is not specified with IronPython.

The "fix" in CodePlex work item 24714 would be suboptimal, because frame
information would be unavailable even if -X:Frames were to be specified.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7014>
_______________________________________

From report at bugs.python.org  Tue Sep 29 09:31:45 2009
From: report at bugs.python.org (Rohde Fischer)
Date: Tue, 29 Sep 2009 07:31:45 +0000
Subject: [issue7012] Tabs is better than spaces for indentation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254209505.67.0.0609218108669.issue7012@psf.upfronthosting.co.za>


Rohde Fischer <krdata at gmail.com> added the comment:

> Python started out using tabs, for some of the reasons you elaborate.
> Years of practical experience have shown that using tabs causes pain.
> Our recommendation is not going to change.
I can't actually see why this should be the case, could you please 
enlighten me here?

> > Then some of the arguments I've heard is that some editors shows
> > tabs badly, although true, then most proper editors it's possible
> > to adjust that to your personal preference
> That is no option for Python. In Python, it is part of the LANGUAGE
> SYNTAX that a tab is 8 columns. Changing that may change the very
> meaning of a Python program (i.e. an editor configured to four column
> tabs may render a program to MEAN something different than when
> formatted to eight column tabs).
I fail to see that this is possible, simply from the following reason 
(space after \t added for readability)
if a<b:
\t if b<c:
\t\t # some code

if that ends up as:
if a<b:
    if b<c:
        # Some code

or
if a<b:
        if b<c:
                # Some code

would be exactly the same (apart from how much space it takes). Unless 
the editor automatically wraps lines or some other - for programming - 
inappropriate things, then the code would be exactly the same as long 
as you use the same indentation all the way, no matter if it's 
interpreted as 2, 4, 8 or n spaces.

As far as I can see no matter how complex the code is this wouldn't 
change, since 1st block = 1 tab || 4 spaces, 2nd block = 2 tabs || 8 
spaces. No matter how many blocks, no matter if the editor shows it as 
x spaces the code is the same. Only requirements is, don't mix tabs and 
spaces (but that counts everywhere, just don't do it ;) ), and that you 
indent when using block code (which is also the same for spaces).

> > In a program with 200 lines of code we have roughly 600 extra
> > keystrokes with spaces, unless using a proper editor which shows
> > tabs nicely.

> I think you should get a different editor then. I press tab in my
> editor and still get four spaces.
Ok I though I managed to make it clear that I know the possibilities of 
editors, but ok. I'm perfectly aware of that possibility, but so far 
I'm not interested. I see no reasons for spaces apart from making a lot 
of things harder without benefits (I still fail to see any benefit)

> > Tabs use less space, which is usable when uploading and downloading
> > code a lot (which you do when using version control).

> That's negligible, compared to the rest of the file.

Might be true, but with the present speed of most free svn server even 
little gained is useful. I'm actually disappointed of how bad their 
download is (just in case someone wonders: I have tested my upload)

> Wow. You (rohdef) really do sound like you are a time capsule from
> the eighties. Tabs would save keystrokes and bandwidth, and are not
> confusing? The keystrokes argument is wrong for most editors;
I'm aware (I'm surprised that it's unclear from what I wrote that I'm 
aware of the most basic capabilities of an IDE, but ok that's besides 
the point), but I'm probably not the only one in the world being forced 
to work on crappy editors from time to time, even though I try to avoid 
it.

> the bandwidth argument doesn't matter due to disk size, network
> speed, and compression;
Although it might not be much I still feel that it's a waste, but as 
far as I see this is the only point where I'm like a time capsule from 
the 80's. But still even little saved matters when using SF og Google 
Code for svn (I was a bit shocked on how slow they are, and to be 
honest I use another that's nice and fast in stead).

> and the confusion is absolutely real.
But none has pointed it out yet, the only confusion I've seen so far is 
from people having contradicting beliefs on the tabs vs spaces. So far 
I've never seen a reason to change my opinion, since I've only seen 
spaces as trouble.

> Pretty much every time I volunteer to help out a group of Python
> newbies there is at least one baffling problem due to tabs/spaces.
> There are hundreds of different text editors that people use on a
> regular basis to edit Python source code. They all display spaces
> the same way; not so for tabs.
The beauty of flexibility :) Besides that I've never seen problems due 
to tabs shown differently as long as it's not treated in some insane 
way that would be inappropriate for an IDE, so I won't consider those.

> Most of them have configurable behavior for tabs, and most of the
> time the users are not aware of even the existence of those settings,
> let alone what setting is currently being used.
And since most developers is unaware of things like compile options in 
compiled languages, should we remove that too? Even though most people 
aren't aware (either because of the lack of need or interest to change 
it) of the settings, there's no reason to remove that for us who know 
and care.


I'll try to say what I indirectly said. Show my why things are like you 
say it is. Why is tabs confusing? Why is spaces better? I can't use 
empty arguments without any proof. I can't use a "it's just like that"-
argument, only thing I can use that for is wasting my time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Tue Sep 29 09:57:40 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 07:57:40 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254178973.99.0.0865778223053.issue7008@psf.upfronthosting.co.za>
Message-ID: <4AC1BDF1.7060105@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Guido van Rossum wrote:
> What's a realistic use case for .title() anyway?

The primary use is when converting a string to be used as
title or sub-title of text - mostly inspired by the way
English treats titles.

The implementation follows the rules laid out in UTR#21:

http://unicode.org/reports/tr21/tr21-3.html

The Python version only implements the basic set of rules, i.e.
"If the preceeding letter is cased, chose the lowercase mapping; otherwise chose the titlecase
mapping (in most cases, this will be the same as the uppercase, but not always)."

It doesn't implement the special casing rules, since these would
require locale and language dependent context information which
we don't implement/use in Python.

It also doesn't implement mappings that would result in a change of
length (ligatures) or require look-ahead strategies (e.g. if the casing
depends on the code point following the converted code point).

Patches to enhance the code to support those additional rules
are welcome.

Regarding the apostrophe: the Unicode standard doesn't appear to
include any rule regarding that character and its use in titles
or upper-case versions of text. The apostrophe itself is a
non-cased code point.

It's likely that the special use of the apostrophe in English
is actually a language-specific use case. For those, it's (currently)
better to implement your own versions of the conversion functions,
based on the existing methods.

Regarding the idea to add an option to define which characters to
regard as cased/non-cased: This would cause the algorithm to no longer
adhere to the Unicode standard and most probably cause more problems
than it solves.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 10:35:52 2009
From: report at bugs.python.org (Mats Kindahl)
Date: Tue, 29 Sep 2009 08:35:52 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1254213352.72.0.338812920874.issue7005@psf.upfronthosting.co.za>


Mats Kindahl <mats at sun.com> added the comment:

Adding patch with the changes requested by Fred.

----------
Added file: http://bugs.python.org/file14993/cfgparser-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Tue Sep 29 10:37:14 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 08:37:14 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <4AC1BDF1.7060105@egenix.com>
Message-ID: <4AC1C736.3070403@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Regarding the apostrophe: the Unicode standard doesn't appear to
> include any rule regarding that character and its use in titles
> or upper-case versions of text. The apostrophe itself is a
> non-cased code point.
> 
> It's likely that the special use of the apostrophe in English
> is actually a language-specific use case. For those, it's (currently)
> better to implement your own versions of the conversion functions,
> based on the existing methods.

Looking at the many different uses in various languages, this
appears to be the better option:

http://en.wikipedia.org/wiki/Apostrophe

To make things even more complicated, the usual typewriter apostrophe
that you find in ASCII is not the only one in Unicode:

http://en.wikipedia.org/wiki/Apostrophe#Unicode

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 10:42:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Sep 2009 08:42:33 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254213753.52.0.0713038412271.issue7008@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Patches to enhance the code to support those additional rules
are welcome.

#6412 has a patch.

----------
assignee:  -> gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 10:57:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 08:57:51 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <4AC1C736.3070403@egenix.com>
Message-ID: <1254214885.5445.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To make things even more complicated, the usual typewriter apostrophe
> that you find in ASCII is not the only one in Unicode:
> 
> http://en.wikipedia.org/wiki/Apostrophe#Unicode

Yup, and the right one typographically isn't necessarily the ASCII
one :-)
That's why Microsoft Word automatically inserts a non-ASCII apostrophe
when you type ? ' ?, at least in certain languages (apparently
OpenOffice doesn't).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:05:48 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 09:05:48 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1254215148.68.0.583827777084.issue6412@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The patch looks good, but it doesn't include the few extra characters
that are also considered case-ignorable:

* U+0027 APOSTROPHE
* U+00AD SOFT HYPHEN (SHY)
* U+2019 RIGHT SINGLE QUOTATION MARK

Could you add those as well ?

Thanks.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:06:50 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 09:06:50 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254213753.52.0.0713038412271.issue7008@psf.upfronthosting.co.za>
Message-ID: <4AC1CE26.70903@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
>> Patches to enhance the code to support those additional rules
> are welcome.
> 
> #6412 has a patch.

That patch looks promising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:20:13 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Tue, 29 Sep 2009 09:20:13 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1254216013.11.0.953096626201.issue6412@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

> * U+0027 APOSTROPHE
hardcoded (see below)
> * U+00AD SOFT HYPHEN (SHY)
has the "Format (Cf)" property and thus is included automatically
> * U+2019 RIGHT SINGLE QUOTATION MARK
hardcoded (see below)

I hardcoded some characters into Tools/unicode/makeunicodedata.py:
>>> print ' '.join([u':', u'\xb7', u'\u0387', u'\u05f4', u'\u2027',
u'\ufe13', u'\ufe55', u'\uff1a'] + [u"'", u'.', u'\u2018', u'\u2019',
u'\u2024', u'\ufe52', u'\uff07', u'\uff0e'])
: ? ? ? ? ? ? ? ' . ? ? ? ? ? ?

Those cannot currently be extracted automatically, as neither
DerivedCoreProperties.txt nor the source file for property
"Word_Break(C) = MidLetter or MidNumLet" are provided in the script.

As I said, the patch is only a second best solution, as the correct
path would be implementing the word breaking algorithm as described in
the newest standard. This patch is just an improvement over the current
situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:44:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 09:44:14 +0000
Subject: [issue7017] os.listdir behaviour
In-Reply-To: <1254208050.64.0.613024688273.issue7017@psf.upfronthosting.co.za>
Message-ID: <1254217454.13.0.750423538005.issue7017@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What's 'FileList' in your code?  (It's not the same as 'fileList', since
Python identifiers are case sensitive.)

What's 'temporaryDirectory'?

Please could you cut and paste an executable code snippet that exhibits
the problem, along with any other instructions necessary to reproduce
(e.g. "First create a directory 'tmp' containing files 'a', 'b' and 'c'").

----------
nosy: +mark.dickinson
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7017>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:44:39 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 09:44:39 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1254216013.11.0.953096626201.issue6412@psf.upfronthosting.co.za>
Message-ID: <4AC1D703.9080002@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Christoph Burgmer wrote:
> 
> Christoph Burgmer <cburgmer at ira.uka.de> added the comment:
> 
>> * U+0027 APOSTROPHE
> hardcoded (see below)
>> * U+00AD SOFT HYPHEN (SHY)
> has the "Format (Cf)" property and thus is included automatically
>> * U+2019 RIGHT SINGLE QUOTATION MARK
> hardcoded (see below)
> 
> I hardcoded some characters into Tools/unicode/makeunicodedata.py:
>>>> print ' '.join([u':', u'\xb7', u'\u0387', u'\u05f4', u'\u2027',
> u'\ufe13', u'\ufe55', u'\uff1a'] + [u"'", u'.', u'\u2018', u'\u2019',
> u'\u2024', u'\ufe52', u'\uff07', u'\uff0e'])
> : ? ? ? ? ? ? ? ' . ? ? ? ? ? ?
> 
> Those cannot currently be extracted automatically, as neither
> DerivedCoreProperties.txt nor the source file for property
> "Word_Break(C) = MidLetter or MidNumLet" are provided in the script.

As long as those code points are defined somewhere in the Unicode
standard files, that's ok.

It would be good to add a comment explaining the above in the code.

BTW: It's better to use "if (....)" instead of \-line joining. The
parens will automatically have Python do the line joining for you
and it looks better.

> As I said, the patch is only a second best solution, as the correct
> path would be implementing the word breaking algorithm as described in
> the newest standard. This patch is just an improvement over the current
> situation.

We could handle the work-breaking in a separate new method.

For .title(), I think your patch is an improvement and it will
fix most of the cases that issue7008 mentions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:46:03 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 29 Sep 2009 09:46:03 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254217563.75.0.237130006526.issue6972@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I think this should clearly be fixed in the code. The current code tries
to handle absolute paths by removing the first slash (unfortunately not
the second), so it looks like it tries to be safe and only write to the
destination directory. That should be the default operation.
I even think that there should be *no* option to allow overriding files
outside the destination path (on unix one can always use / as
destination if he feels like overwriting his /etc/passwd)
The documentation should also mention that it's unsafe to use this
method in python <2.6.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 11:48:03 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 29 Sep 2009 09:48:03 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254217683.82.0.718434632067.issue6972@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

The documentation should also mention that it's unsafe to use this
method in python <= 2.6.2. 2.6.2 is also unsafe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:07:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 10:07:10 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254218830.78.0.40485433825.issue6790@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

issue6790-python2.6.diff is ok, can you commit to trunk and then merge?

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:20:47 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Tue, 29 Sep 2009 10:20:47 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254219647.05.0.244296326279.issue7008@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

I admit I don't fully understand the semantics of capwords(). But from
what I believe what it should do, this function could be happily
replaced by the word-breaking algorithm as defined in
http://www.unicode.org/reports/tr29/.

This algorithm should be implemented anyway, to properly solve
issue6412.

----------
nosy: +christoph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:34:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 10:34:26 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254219647.05.0.244296326279.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254220122.5445.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This algorithm should be implemented anyway, to properly solve
> issue6412.

Sure, but it should be another function, which might have its place in
the wordwrap module.

capwords() itself could be deprecated, since it's an obvious one-liner.
Replacing in with another method, however, will just confuse and annoy
existing users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:40:30 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Tue, 29 Sep 2009 10:40:30 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1254220830.62.0.0821993509027.issue6412@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

New patch
  - updated comments to reflect needed integration of
DerivedCoreProperties.txt
  - cleaned up if(...) construct
  - updated (from issue7008) and integrated testcase

When applying this patch, run Tools/unicode/makeunicodedata.py to
regenerate the header files.

Note though, that with this patch str and unicode objects will not
behave equally:
>>> s = "This isn't right"
>>> s.title() == unicode(s).title()
False

----------
Added file: http://bugs.python.org/file14994/unicodeobject.titlecase.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:40:55 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 10:40:55 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254219647.05.0.244296326279.issue7008@psf.upfronthosting.co.za>
Message-ID: <4AC1E435.9030908@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Christoph Burgmer wrote:
> 
> Christoph Burgmer <cburgmer at ira.uka.de> added the comment:
> 
> I admit I don't fully understand the semantics of capwords().

string.capwords() is an old function from the days before Unicode.
The function is basically defined by its implementation.

> But from
> what I believe what it should do, this function could be happily
> replaced by the word-breaking algorithm as defined in
> http://www.unicode.org/reports/tr29/.
> 
> This algorithm should be implemented anyway, to properly solve
> issue6412.

Simple word breaking would be nice to have in Python as new
Unicode method, e.g. .splitwords().

Note however, that word boundaries are just as complicated as casing:
there are lots of special cases in different languages or locales
(see the notes after the word boundary rules in the TR29).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:56:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 10:56:47 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1254221807.36.0.262703180377.issue6071@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After thinking about it, we should remover the bf_releasebuffer checks
when using the old typecodes '#' (the doc should also clearly state that
these are unsafe and '*' is preferred).

If a type chooses to implement the /old/ buffer API and if a method
requires the /old/ buffer API instead of the new one (that is, by using
a '#' typecode), we have to accept these choices.

Here's a patch for trunk, combining the new buffer API for `array` and
the checks removal in getargs.c.

----------
Added file: http://bugs.python.org/file14995/hasharray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Tue Sep 29 12:59:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 10:59:16 +0000
Subject: [issue7018] Recommend "*" over "#" in getargs.c typecodes
In-Reply-To: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za>
Message-ID: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In ? Parsing arguments and building values ? (c-api/arg.html), it should
be made clear that "*" typecodes are recommended over the "#" typecodes,
which are inherently unsafe.

(more generally, the page is totally unreadable, a solution might be to
group the typecodes by family: numbers, strings/buffers, objects; also,
there are so many choices that it's confusing which ones should be
preferred)

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 93276
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Recommend "*" over "#" in getargs.c typecodes
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7018>
_______________________________________

From report at bugs.python.org  Tue Sep 29 13:01:33 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Tue, 29 Sep 2009 11:01:33 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254222093.11.0.58452995351.issue7008@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Antoine Pitrou wrote:
> capwords() itself could be deprecated, since it's an obvious one-
> Replacing in with another method, however, will just confuse and
annoy
> existing users.

Yes, sorry, I meant the semantics, where as you are right for the
specific function.

Marc-Andre Lemburg wrote:
> Note however, that word boundaries are just as complicated as casing:
> there are lots of special cases in different languages or locales
> (see the notes after the word boundary rules in the TR29).

ICU already has the full implementation, so Python could get away with
just supporting the default implementation (as seen with other case
mappings).

>>> from PyICU import UnicodeString, Locale, BreakIterator            
>>> en_US_locale = Locale('en_US')                                    
>>> breakIter = BreakIterator.createWordInstance(en_US_locale)        
>>> s = UnicodeString("There's a hole in the bucket.")                
>>> print s.toTitle(breakIter, en_US_locale)
There's A Hole In The Bucket.
>>> breakIter.setText("There's a hole in the bucket.")
>>> last = 0
>>> for i in breakIter:
...     print s[last:i]
...     last = i
...
There's

A

Hole

In

The

Bucket
.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 13:02:04 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Sep 2009 11:02:04 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254222124.79.0.178992111361.issue6972@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The tarfile module solved this issue with a documentation warning:
http://docs.python.org/library/tarfile.html#tarfile.TarFile.extractall

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 13:14:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 11:14:50 +0000
Subject: [issue7018] Recommend "*" over "#" in getargs.c typecodes
In-Reply-To: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za>
Message-ID: <1254222890.91.0.27152559361.issue7018@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This only really applies in 2.x, actually. In 3.x, "#" should be
discouraged for another reason: it is overly strict and will only accept
pure read-only objects (which don't have a bf_releasebuffer method);
even bytearrays will be rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7018>
_______________________________________

From report at bugs.python.org  Tue Sep 29 13:43:00 2009
From: report at bugs.python.org (Tim Peters)
Date: Tue, 29 Sep 2009 11:43:00 +0000
Subject: [issue7012] Tabs is better than spaces for indentation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254224580.13.0.0586554306272.issue7012@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I understand you're annoyed, but the bug tracker is not the place to
rehash arguments that were settled a decade ago.  If you need to pursue
this, please take it to the newsgroup comp.lang.python.  Before you do,
you might want to scour the newsgroup's archives, as millions of words
of debate on this topic have already taken place, mostly in the early to
mid 90's.  Nobody has anything new to say on this topic :-(

Note that nobody objects if you want to use tabs, or even mix tabs and
spaces, in your own code.  The Python "spaces only" standard is for
distributed code.  Years of early experience taught us beyond doubt that
tabs caused endless problems for /shared/ code, to the extent that the
Python distribution contains utilities to detect when mixing tabs and
spaces can cause semantic differences (tabnanny.py) and to reformat
source files to replace all tabs with spaces (reindent.py).

Indeed, if you want to contribute to the Python distribution and insist
on using tabs, that's fine:  simply run your code through reindent.py
before submitting your patch.  Otherwise, just like this feature
request, your patch will be rejected ;-)

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Tue Sep 29 13:51:41 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Sep 2009 11:51:41 +0000
Subject: [issue7016] .pyc files are set executable if the .py file is too
In-Reply-To: <1254207434.5.0.560245182019.issue7016@psf.upfronthosting.co.za>
Message-ID: <19137.62660.630633.794514@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Steven> $ echo pass > test.py
    Steven> $ chmod u+x test.py
    Steven> $ python2.6 -c "import test"
    Steven> $ ls -l test.pyc
    Steven> -rwxrw-r-- 1 steve steve 94 2009-09-29 16:54 test.pyc
    Steven> $ ./test.pyc
    Steven> : command not found   

And if you try ./test.py I presume you also get an error in this trivial
case.  If your .py file is not meant to be executed, why set the execute
bit?  I do agree it's a little strange to also set the execute bit on the
.pyc file though.

Skip

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7016>
_______________________________________

From report at bugs.python.org  Tue Sep 29 14:12:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 12:12:13 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254226333.3.0.160701998605.issue7015@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's a problem with one of your installed modules. I don't think Python
can do anything, unless you propose silencing all errors.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Tue Sep 29 14:15:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Sep 2009 12:15:13 +0000
Subject: [issue7016] .pyc files are set executable if the .py file is too
In-Reply-To: <1254207434.5.0.560245182019.issue7016@psf.upfronthosting.co.za>
Message-ID: <1254226513.76.0.122989824665.issue7016@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 6070, and has been fixed.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Python 2.6 makes .pyc/.pyo bytecode files executable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7016>
_______________________________________

From report at bugs.python.org  Tue Sep 29 14:16:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 12:16:02 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254226562.01.0.0567591205184.issue6992@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The good pratice, if there are several authors, is to setup a
mailing-list (and put its address as official contact address).
Otherwise collaboration gets inevitably messy, since authors can get
contacted in private randomly.

I don't think we should multiply those fields in order to accomodate for
subtle role differences. Also, I don't think PyPI is the place to record
detailed attribution information. An ad-hoc CREDITS, ACKS file or
similar is what you want IMO.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:09:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 29 Sep 2009 13:09:04 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254229744.05.0.910067175945.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

What you are saying is that a project should have one and only one
contact email. What Anatoly says is that a project should be able to
have several authors.

What about having a "Contact-email" then that would replace the
"Author-email" field, and an "Author" multi-valued field as described
previously.

Having an extra email in each Author field would be allowed but not
parsed. Each Author field would be a free string that can be "Name",
"Firstname Lastname", "Firstname Lastname <email>" or whatever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:18:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 13:18:13 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254229744.05.0.910067175945.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254230507.5445.18.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What about having a "Contact-email" then that would replace the
> "Author-email" field, and an "Author" multi-valued field as described
> previously.

Why do we have to add new fields and deprecate others? Just for the sake
of confusing users and breaking existing packages? What do we gain
exactly? There are enough fields available to make the writing of a
setup.py burdensome...

If you have several authors, you can separate them with commas in the
author field and even include e-mail addresses if you want (e.g. "Tarek
Ziad? <tarek at example.com>, Antoine Pitrou <antoine at example.net>"). 

Not every wish for a new "feature" should be satisfied, IMO. Besides,
making metadata complex and version-dependent is the best way to make it
useless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:28:12 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 29 Sep 2009 13:28:12 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254230892.05.0.722067747602.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The metadata are completely messy. Users are already confused.

For instance, since the metadata fields are not fully corresponding to
the argument names you can pass into setup.py, you can have an "author"
and a "maintainer" argument and Distutils will put only the author one
in the metadata field "Author".

To fill the "Home-url" metadata, the argument is called "url".
The "Summary" metadata is filled with the... "description" argument
The "Description" metadata is filled with the... "long_description"
argument.

So what we would gain is more clarity (as already discussed in other issues)

We are already discussing the addition of new fields in PEP 341 for
package dependencies, and making others clearer.

Replacing the author/author_email/maintainer/maintainer_email mess with
a single authors argument, that fills a multi-valued "Author" metadata
field make it clearer. Same thing goes with the email issue.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:32:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 13:32:00 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254230892.05.0.722067747602.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254231334.5445.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Replacing the author/author_email/maintainer/maintainer_email mess with
> a single authors argument, that fills a multi-valued "Author" metadata
> field make it clearer.

What does changing the type of the "author" field make clearer exactly?
It is a field for human beings to read, and a human being is perfectly
able to parse "AP <ap at example.com>, Tarek <tarek at example.com>" without
the help of a computer.

While there may be some things to clear up in the current metadata, this
shouldn't be a pretext to gratuitously change things that are ok. I'm
bothered that many people currently seem to think that it's ok to break
compatibility for whatever non-critical reason. This is not the way we
will make Python a reliable platform to use and develop for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:45:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 29 Sep 2009 13:45:02 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254231902.01.0.0642377880596.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> What does changing the type of the "author" field make clearer exactly? 

It "Author" not "Authors", that's the difference. Like we have
"Classifiers" and not "Classifier".

Plus, I am not breaking any compatibility here.

A multi-value field in the metadata in Distutils just means that you
might find several lines starting with 

{{{
Author:
}}}

And that Distutils will be able to recognized both forms, exactly like
it does with Metadata v1.0 and metadata v1.1.

> I'm bothered that many people currently seem to think that it's ok 
> to compatibility for whatever non-critical reason. This is not 
> the way we will make Python a reliable platform to use and develop for.

I don't know who you are reffering to, but if you look carefully at the
work I've been doing in Distutils, I have never and I will never do any
gratuitously change whatsoever. 

I am bothered that more and more are people constantly jumping on my
back everytime I try to make Distutils evolves a bit or everytime I
discuss some feature proposals with the community.

Any change to the metadata fields will require a PEP 341 change, so
everyone will be free to do a +1 or a -1.

But saying that making the metadata evolve "is not the way we will make
Python a reliable platform to use and develop for" is completely
wrong imho.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:50:53 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 13:50:53 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254232253.94.0.260473288596.issue6992@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Most of the meta data is parsed by humans, so I don't see any
complication with adding multiple authors to the author field using
standard email format: "Anatoli <email at here>, Tarek <email at here>".

We already have authors and maintainers (which causes confusion), so
adding yet another field for contributors is overkill, IMHO. It's common
practice to put credits into a README or separate file within the package.

I don't think we should grow the package meta-data beyond what's
reasonably needed to identify a package and its origin - otherwise we'll
end up with a reinvention of RDF.

I'd close this ticket as "works for me".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:09:22 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 29 Sep 2009 14:09:22 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254233362.38.0.701858990991.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> We already have authors and maintainers (which causes confusion), 
> adding yet another field for contributors is overkill,

Not on the Metadata side though. That's only on setup() side. The
resulting metadata only contains "Author" and "Author-email", and it's
calculated using 'author' *or* 'maintainer' arguments. Meaning that when
you fill both, one is lost. (and leading to the current inconsistency).

So being able to have several Authors (not yet another field, an
existing one, but multi-valued) and an "authors" argument would fix this
inconsistency since we would be able to keep both.

This is not a big change on the metadata format, it just means that we
can have extra "Author:" lines, so it's backward compatible.

OTHO, deprecating "maintainer" and "maintainer_email" on setup() side,
and making it clear that there's only one Author and one email could
work too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 15:54:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 13:54:35 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254231902.01.0.0642377880596.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254232690.5445.30.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am bothered that more and more are people constantly jumping on my
> back everytime I try to make Distutils evolves a bit or everytime I
> discuss some feature proposals with the community.

This is not "jumping on your back", this is being skeptical about a
detail that doesn't seem to warrant a change. It is still unknown what
use case the new "author" scheme would solve that the old one doesn't
(does someone want the "author" field to be machine parsable? for what
purpose?), and this bug report itself is quite nebulous (it is unsure
what "doesn't work" since you can put human-readable info about multiple
authors in a single unicode string).
That's why I call it "gratuitous".

> But saying that making the metadata evolve "is not the way we will make
> Python a reliable platform to use and develop for" is completely
> wrong imho.

A metadata system, by definition, has to remain reasonably stable (or be
version-numbered, such that old metadata can be recognized properly).
You can certainly add fields, but replacing existing fields with others
should be sufficiently motivated.

If the ID3 spec was rewritten every five years so that you couldn't read
back the author info from the MP3s you made in 2000, you wouldn't be
very happy :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:24:58 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 14:24:58 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254233362.38.0.701858990991.issue6992@psf.upfronthosting.co.za>
Message-ID: <4AC218B6.10006@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> 
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
>> We already have authors and maintainers (which causes confusion), 
>> adding yet another field for contributors is overkill,
> 
> Not on the Metadata side though. That's only on setup() side. The
> resulting metadata only contains "Author" and "Author-email", and it's
> calculated using 'author' *or* 'maintainer' arguments. Meaning that when
> you fill both, one is lost. (and leading to the current inconsistency).
>
> So being able to have several Authors (not yet another field, an
> existing one, but multi-valued) and an "authors" argument would fix this
> inconsistency since we would be able to keep both.
> 
> This is not a big change on the metadata format, it just means that we
> can have extra "Author:" lines, so it's backward compatible.
> 
> OTHO, deprecating "maintainer" and "maintainer_email" on setup() side,
> and making it clear that there's only one Author and one email could
> work too.

In order to clear up the inconsistency with maintainer not
being a possible meta-data field, I think "Maintainer" should
be added to the meta-data. Dito for "Maintainer-EMail".

Regarding making the meta-data fields multi-valued, you have
to be aware that when parsing the meta-data using an rfc822
style module, code assuming that only one Author field
exists, will return (just) one of the available fields and
it's not at all clear which.

I still believe that we're better off with a single Author
field using comma delimited names, e-mail addresses, etc.

Adding "authors" as new keyword argument to setup() isn't
going to make things more consistent, only more complex
code-wise, so I don't think it's worth the trouble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:28:41 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 29 Sep 2009 14:28:41 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254234521.55.0.444727522841.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> A metadata system, by definition, has to remain reasonably stable 
> (or be version-numbered, such that old metadata can be recognized
properly).

That's already the case. We have 1.0 and 1.1. 

1.1 is used if you add fields like "obsoletes".


> You can certainly add fields, but replacing existing fields with 
> others should be sufficiently motivated.

Yes, that why the proposed change is backward compatible: it doesn't
replace "Author" but turn it into a multi-valued field like
"Classifier". Either you have one author line, and the metadata is 1.0
or 1.1, Either you have several authors, and the metadata is 1.2 and
doesn't modify Author but add more of those lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:35:59 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Tue, 29 Sep 2009 14:35:59 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

When unmarshalling a hand-written string it is possible to break the
invariants of longs:

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.
>>> x = marshal.loads('l\x02\x00\x00\x00\x00\x00\x00\x00')
>>> print x
00000
>>> x == 0
False
>>> bool(x)
True
>>> x + 1
1L

I would expect this to raise an error instead.

----------
components: Interpreter Core
messages: 93295
nosy: cfbolz
severity: normal
status: open
title: unmarshaling of artificial strings can produce funny longs.
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:45:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 29 Sep 2009 14:45:30 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254235530.27.0.87399883696.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> In order to clear up the inconsistency with maintainer 
> not being a possible meta-data field, I think "Maintainer" 
> should be added to the meta-data. Dito for "Maintainer-EMail".

Do you remember what's the story behind those two fields ?

I am not sure about the community usage of those since they are competng
with author and author_email on setup() side

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:45:41 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Sep 2009 14:45:41 +0000
Subject: [issue7012] Tabs is better than spaces for indentation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254235541.69.0.412820589092.issue7012@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:47:31 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Tue, 29 Sep 2009 14:47:31 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254235651.57.0.952903240086.issue7019@psf.upfronthosting.co.za>


Changes by Carl Friedrich Bolz <cfbolz at gmx.de>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:49:21 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Sep 2009 14:49:21 +0000
Subject: [issue7008] str.title() misbehaves with apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254235761.13.0.0161893053761.issue7008@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________

From report at bugs.python.org  Tue Sep 29 16:56:44 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2009 14:56:44 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254235530.27.0.87399883696.issue6992@psf.upfronthosting.co.za>
Message-ID: <4AC22029.506@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> 
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
>> In order to clear up the inconsistency with maintainer 
>> not being a possible meta-data field, I think "Maintainer" 
>> should be added to the meta-data. Dito for "Maintainer-EMail".
> 
> Do you remember what's the story behind those two fields ?

I don't really remember, but suppose that the field was
added for cases where a package is being abandoned by the
original author and then maintained by someone new.

IMHO, the maintainer could have just added the new contact
details to the author field and a mention of the changed
maintenance to the description.

> I am not sure about the community usage of those since they are competng
> with author and author_email on setup() side

PyPI just shows the "Author" field, so if a package has different
author and maintainer entries, the author field is what's displayed -
not exactly useful, since bug reports and the like should normally
go to the maintainer, not the author.

Adding the maintainer field as well would resolve the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Tue Sep 29 17:14:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 15:14:38 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254237278.08.0.748576625583.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report;  I'll take a look.

Though in general, I think this comes under the heading of 'Don't do
that, then.'  I suspect there are many ways to produce odd behaviour by
feeding malformed input to marshal.  See the big pink boxes at:

http://docs.python.org/library/marshal.html

:-)

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 17:25:15 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Tue, 29 Sep 2009 15:25:15 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254237915.69.0.552226416295.issue7019@psf.upfronthosting.co.za>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

Yes, I know :-). I thought I'd report it anyway, as it does more than
"just" give you random behavior, but actually produces a broken object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 17:58:43 2009
From: report at bugs.python.org (Tim Flechtner)
Date: Tue, 29 Sep 2009 15:58:43 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1254239923.41.0.222454769167.issue1759169@psf.upfronthosting.co.za>


Tim Flechtner <timf at trdlnk.com> added the comment:

Hi.  I think I'm running into the problem discussed in this ticket.  I'm
trying to build pycairo-1.8.8 on Solaris 10 (x86) against python-2.6.2
using gcc-4.4.1.  I'm afraid I'm out of my depth in understanding really
what's going on, but the error I get looks like it fits the symptoms
described here.  Can anyone point me towards the patch to apply?  I
don't see it as available here (but I wouldn't be shocked if I'm just
being blind).

Thanks!
-tim

gmake[2]: Entering directory
`/export/home/src/ThirdParty/gnu/pycairo-1.8.8/src'
/bin/bash ../libtool  --tag=CC   --mode=compile
/opt/app/g++lib6/gcc-4.4/bin/gcc -DHAVE_CONFIG_H -I. 
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/nonc++/release-1/include/cairo   -DNDEBUG  -g -O2 -std=c99
-Wall -fno-strict-aliasing -MT _cairo_la-cairomodule.lo -MD -MP -MF
.deps/_cairo_la-cairomodule.Tpo -c -o _cairo_la-cairomodule.lo `test -f
'cairomodule.c' || echo './'`cairomodule.c
libtool: compile:  /opt/app/g++lib6/gcc-4.4/bin/gcc -DHAVE_CONFIG_H -I.
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/nonc++/release-1/include/cairo -DNDEBUG -g -O2 -std=c99 -Wall
-fno-strict-aliasing -MT _cairo_la-cairomodule.lo -MD -MP -MF
.deps/_cairo_la-cairomodule.Tpo -c cairomodule.c  -fPIC -DPIC -o
.libs/_cairo_la-cairomodule.o
In file included from /usr/include/limits.h:18,
                 from
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/limits.h:122,
                 from
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/syslimits.h:7,
                 from
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/limits.h:11,
                 from
/opt/app/g++lib6/python-2.6/include/python2.6/Python.h:19,
                 from cairomodule.c:32:
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/sys/feature_tests.h:341:2:
error: #error "Compiler or options invalid for pre-UNIX 03 X/Open
applications       and pre-2001 POSIX applications"

----------
nosy: +tflecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Tue Sep 29 18:31:06 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 16:31:06 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1254241866.76.0.252830182819.issue6071@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Moving to deferred blocker to get this out of the way for 2.6.3

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Tue Sep 29 18:35:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 16:35:44 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1254242144.31.0.0554711609917.issue6990@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Tue Sep 29 18:39:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 16:39:45 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254242385.27.0.666380819372.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So there are two options:  (1) raise an exception, or (2) strip leading 
zero digits and produce a properly normalized Python long.  Do you have 
any strong preferences?  I'm inclined towards (2).

How did you encounter this in the first place?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 18:48:26 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 29 Sep 2009 16:48:26 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254242906.75.0.211685093264.issue7019@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/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 18:55:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 16:55:35 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254243335.71.0.437378828653.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On second thoughts, I think Carl was right in the first place: it's better 
to raise an exception.  If marshal.loads is getting input that doesn't 
precisely match the marshal.dumps format, then something's wrong 
somewhere.

Looks like we missed the window for 2.6.3.  :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:17:28 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 29 Sep 2009 17:17:28 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1254244648.82.0.353784528961.issue5329@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Here's the doc change with a lil more clarification, and I've also applied 
it to the module's own docs

----------
Added file: http://bugs.python.org/file14996/subprocess-conversion-doc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:20:09 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 17:20:09 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254244809.86.0.528071888958.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

My working solution is to iterate through members, and ensuring that
os.path.abspath(os.path.join(path, member)) always .startswith(path).
This seems like a better solution than trying to trap on a pattern in
the string. Presumably the same fix can be made to tarfile.

For what it's worth, OS X's BOMArchiveManager will place a file stored
as '../foo.txt' in the extract path, not the directory right outside it.

While we're on the topic, there may also be a bug in this, or the
tarfile package that would allow a malicious archive to extract a
symlink to an existing directory somewhere on the target machine, and
files extracted to that symlink. I haven't really thought that through,
but I'm sure that my fix won't correct that possible issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:33:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 17:33:31 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254245611.92.0.987815279268.issue6790@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:39:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 17:39:06 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254245946.7.0.163027846842.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for Python 2.6.

----------
keywords: +patch
Added file: http://bugs.python.org/file14997/issue7019_26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:47:47 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 29 Sep 2009 17:47:47 +0000
Subject: [issue7014] Logging incompatible with IronPython
In-Reply-To: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>
Message-ID: <1254246467.71.0.380009890929.issue7014@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Works for me - thanks Vinay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7014>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:54:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 17:54:18 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254246858.21.0.985732818542.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And a patch for trunk.  (Significantly different, because marshal for 
Python longs was reworked when 30-bit long digits were added.)

----------
Added file: http://bugs.python.org/file14998/issue7019_trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 19:57:12 2009
From: report at bugs.python.org (Jan Hosang)
Date: Tue, 29 Sep 2009 17:57:12 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1254247032.25.0.259407206706.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I was looking at the remaining differences between Modules/arraymodule.c 
in python 2.7 and the 3k branch, in particular I was testing why 
including the changes to the function array_ass_slice into the patch 
breaks the unit test of the array module.

The manual resizing of the memory basically was replaced by a call to 
array_resize with the advantage, that checking for exported memory views 
is done there (which is not necessary because it's already done in the 
function) and the code gets clearer. I think when PyMem_RESIZE is called 
the pointer to the memory might change. So in 3k this now happens in 
array_resize, so the array->ob_item pointer changes but not it's local 
copy in array_ass_slice. Isn't that potentially causing trouble in 
python 3k?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Tue Sep 29 20:00:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 18:00:20 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254247220.39.0.58179520205.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Changing versions:  3.1 and 3.2 also need fixing (the trunk patch should 
be easily mergeable);  it's not a security issue (AFAIK), so won't be 
fixed in 2.5.

----------
priority:  -> normal
versions: +Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 20:12:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 18:12:35 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1254247955.3.0.498652007469.issue6990@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I get the following failure on py3k:

test test_threading_local failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_threading_local.py",
line 107, in test_derived_cycle_dealloc
    self.assertTrue(passed)
AssertionError: False is not True

----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Tue Sep 29 20:16:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 18:16:01 +0000
Subject: [issue6990] threading.local subclasses don't cleanup their state and
	it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1254248161.33.0.255319582888.issue6990@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Of course, I had forgotten to rebuild :-/ Sorry for the noise.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________

From report at bugs.python.org  Tue Sep 29 20:31:10 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 18:31:10 +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: <1254249070.43.0.548978000712.issue6108@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Since we do not yet have a patch for this, I'm knocking it off the list
for 2.6.3.  It seems like an annoying loss of compatibility, but do we
have any reports of it breaking real-world code?

----------
nosy: +barry
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Tue Sep 29 20:49:15 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 18:49:15 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1254250155.9.0.0938836639015.issue5329@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> pjenvey
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Tue Sep 29 20:54:58 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 18:54:58 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254250498.17.0.706050844032.issue3890@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'd like to accept this for 2.6.3, but I'd also really like a test for
this change.  Giampaolo, do you think you could whip up a test for this.
 I know it's short notice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:03:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 19:03:23 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1254251003.43.0.362964994877.issue6790@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r75134, r75135, r75137, r75142. Thanks!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:10:27 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 29 Sep 2009 19:10:27 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254251427.89.0.871998503858.issue3890@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I could give it a try but I'm not sure I'll be in time for 2.6.3 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:11:42 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 19:11:42 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254251502.13.0.305541013975.issue3890@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Gaimpaolo thanks.  Please give it a try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:19:58 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 29 Sep 2009 19:19:58 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1254251998.54.0.74290245507.issue5329@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

applied in r75143/r75144, in time for 2.6.3. thanks!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:27:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Sep 2009 19:27:00 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254252420.51.0.0230125934175.issue7019@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r75141 (trunk), r75145 (py3k) and r75146 (release31-maint).  I'll 
apply the 2.6 fix once the release26-maint branch is unfrozen.

----------
versions:  -Python 2.4, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:28:50 2009
From: report at bugs.python.org (Jan Hosang)
Date: Tue, 29 Sep 2009 19:28:50 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1254252530.0.0.616212468838.issue6071@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I fixed the array_ass_slice for python 2.7 in the attached patch.

The problem should apply to python 3k as well: firstly the above which 
might stay unnoticed and secondly the function moves to much memory if the 
array size is increased: (Py_SIZE(a)-d-ihigh) items should be moved, 
because Py_SIZE(a) was already modified by array_resize, but the function 
moves (Py_SIZE(a)-ihigh) items.

The attached patch for python 2.7 passes all unit tests for me.

----------
Added file: http://bugs.python.org/file14999/hasharray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:31:12 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 19:31:12 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1254252672.91.0.243715767421.issue6957@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Please apply this for 2.6.3rc1

----------
priority:  -> release blocker
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:35:29 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 29 Sep 2009 19:35:29 +0000
Subject: [issue6957] Extension modules fail to build on OS X 10.6 using
	python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1254252929.23.0.915253563398.issue6957@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r75147 (trunk) and r75148 (2.6)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:36:05 2009
From: report at bugs.python.org (David Bonner)
Date: Tue, 29 Sep 2009 19:36:05 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254252965.04.0.942695893414.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

I've got a patch that fixes this.  It allows BZ2File to read
multi-stream files as generated by pbzip2, allows BZ2File to open files
in append mode, and also updates bz2.decompress to allow it to handle
multi-stream chunks of data.

We originally wrote it against 2.5, but I've updated the patch to py3k
trunk, and attached it here.  If there's interest in a patch against 2.7
trunk, please let me know.

----------
nosy: +dbonner
versions: +Python 2.5, Python 3.2
Added file: http://bugs.python.org/file15000/bz2_patch.tar.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:47:33 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 29 Sep 2009 19:47:33 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254253653.38.0.148741514276.issue3890@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Uhm... I'm sorry but actually I'm not sure about this patch anymore.
Now that I look at ssl.py again I'm noticing that send() is trapped in a 
"while True" loop as well and the patch doesn't cover it.

Not sure if that has been added recently or it was already there at the 
time I submitted the report but it's another thing that need to be 
fixed.


Moreover, I'm sure that removing the "while" loop is good for non-
blocking sockets but what about blocking ones?
Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised 
in a blocking environment?
If they aren't then the current patch just needs to take care of send() 
method too, then it's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 21:51:51 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 29 Sep 2009 19:51:51 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254253911.3.0.483961189994.issue3890@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:02:08 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Sep 2009 20:02:08 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1254254528.65.0.598293247913.issue1759169@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:04:15 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 20:04:15 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254254655.95.0.110207360554.issue3890@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for the feedback Giampaolo.  It sounds like this patch is not yet
fully baked so I'll defer it to Python 2.6.4.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:06:34 2009
From: report at bugs.python.org (David Bonner)
Date: Tue, 29 Sep 2009 20:06:34 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254254794.06.0.275359864046.issue1625@psf.upfronthosting.co.za>


Changes by David Bonner <dbonner at vmware.com>:


Removed file: http://bugs.python.org/file15000/bz2_patch.tar.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:07:07 2009
From: report at bugs.python.org (David Bonner)
Date: Tue, 29 Sep 2009 20:07:07 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254254827.2.0.377561341796.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

sorry, the previous patch was from an old version.  attaching the
correct version now.  apologies for the noise.

----------
Added file: http://bugs.python.org/file15001/bz2_patch.tar.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:11:55 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 29 Sep 2009 20:11:55 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254255115.65.0.497850807194.issue3890@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

You're very welcome.
My only concern is about the blocking environment.
If someone is able to confirm that those exceptions aren't raised with 
blocking sockets then modifying the patch is very trivial and maybe we 
could even make it for 2.6.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:14:14 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 20:14:14 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254255254.25.0.180087771186.issue3890@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

We'll need tests to include it in 2.6.3.

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:43:01 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 29 Sep 2009 20:43:01 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1254256981.93.0.221736476189.issue1759169@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

In msg82274 MvL wrote: "I can grudgingly accept removal of _XOPEN_SOURCE
on Solaris 5.{9,10,11} (?), to work-around this system limitation."

Great!  That's what the attached patch does.  So please apply that patch
and then people can stop coming to this ticket saying that they couldn't
compile their extension modules until they applied the patch.

Also then the Solaris folks who build an installation of Python for
Solaris can remove the perl script that searches for "#define
_XOPEN_SOURCE" and replaces it with the empty string when building Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:51:35 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 20:51:35 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254257495.35.0.0500247638222.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Uploading test.

----------
keywords: +patch
Added file: http://bugs.python.org/file15002/zipfile-6972-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:53:18 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 20:53:18 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254257598.98.0.400133593626.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Uploading patch. This actually should fix my theoretical symlink bug
since realpath() properly follows symlinks. The only thing that I
haven't been able to test is the behavior of realpath() on
case-insensitive operating systems. This should do the right thing, the
path should be normalized, but can someone confirm this?

----------
Added file: http://bugs.python.org/file15003/zipfile-6972-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 22:59:19 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 29 Sep 2009 20:59:19 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254257959.51.0.335802930932.issue6972@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 23:10:12 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 21:10:12 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254258612.54.0.2676339886.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

As for the documentation, it might be a wise idea to up date the current
documentation to mention this issue, until the next release. I'm not
really sure what the process is for doing that, though...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 23:35:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Sep 2009 21:35:16 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254260116.94.0.0462651972403.issue6972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patches to the docs, just like patches to the code (the docs are in the
Doc subdirectory).  Once committed, they get auto-generated and uploaded.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Tue Sep 29 23:58:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 29 Sep 2009 21:58:54 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254261534.41.0.336313001805.issue6972@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Documentation note added (copied from tarfile) in trunk r75149, 
release26-maint r75150 (hopefully in time for 2.6.3 but thats up to 
Barry).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 00:30:24 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Sep 2009 22:30:24 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254263424.67.0.998079716305.issue3890@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Not gonna make it for 2.6.3rc1

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Sep 30 00:36:25 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 29 Sep 2009 22:36:25 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254263785.3.0.853522100407.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

zf.extract() is unsafe for the same reason. My patch fixes this issue,
but we should mention the possible bug in the documentation there as
well. They do this for the similar bug in tarfile.

I've copy/pasted the mention in tarfile.extract() to zipfile.extract()
into the diff.

----------
Added file: http://bugs.python.org/file15004/extract-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 01:09:47 2009
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 29 Sep 2009 23:09:47 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254265787.09.0.0769425871332.issue3890@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I wonder if there is any way to test this, aside from the tests that
are already in the test suite?  The bug here is that the code effectively
does a blocking read on a non-blocking socket, and we can't tell the
difference.  The fact that this patch passes all the existing tests and
also seems to be a fix (through inspection) may have to be sufficient.

After all, the tests for the previous SSL support (Python 2.5 and
earlier) were extremely sketchy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Sep 30 01:32:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 23:32:46 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1254252530.0.0.616212468838.issue6071@psf.upfronthosting.co.za>
Message-ID: <1254267380.5662.20.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I fixed the array_ass_slice for python 2.7 in the attached patch.

I would prefer if I opened a separate issue for this bug. That way it
will be easier to port the patch separately to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Wed Sep 30 01:41:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 23:41:35 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1254267380.5662.20.camel@localhost>
Message-ID: <1254267910.5662.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would prefer if I opened a separate issue for this bug.

if /you/ opened, of course...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6071>
_______________________________________

From report at bugs.python.org  Wed Sep 30 02:14:08 2009
From: report at bugs.python.org (Chris Adamson)
Date: Wed, 30 Sep 2009 00:14:08 +0000
Subject: [issue7017] os.listdir behaviour
In-Reply-To: <1254208050.64.0.613024688273.issue7017@psf.upfronthosting.co.za>
Message-ID: <1254269648.94.0.775792223578.issue7017@psf.upfronthosting.co.za>


Chris Adamson <cadamson at internode.on.net> added the comment:

I think I found my problem. Since I didn't *COPY* the array that I
created with os.listdir I was actually appending to it, my bad.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7017>
_______________________________________

From report at bugs.python.org  Wed Sep 30 04:20:34 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 02:20:34 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Today's 2.6.3rc1 introduced an regression in building pywin32. Peruse
the following error:

=========================================================
creating build\lib.win32-2.6\pywin32_system32
C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL
/nologo /INCREMENTAL:NO
/LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\libs
/LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\PCbuild
/LIBPATH:build\temp.win32-2.6\Release "/LIBPATH:C:\Program
Files\Microsoft SDKs\Windows\v6.0\lib" advapi32.lib user32.lib ole32.lib
oleaut32.lib /EXPORT:initpywintypes
build\temp.win32-2.6\Release\win32\src\PyACL.obj
build\temp.win32-2.6\Release\win32\src\PyDEVMODE.obj
build\temp.win32-2.6\Release\win32\src\PyHANDLE.obj
build\temp.win32-2.6\Release\win32\src\PyIID.obj
build\temp.win32-2.6\Release\win32\src\PyLARGE_INTEGER.obj
build\temp.win32-2.6\Release\win32\src\PyOVERLAPPED.obj
build\temp.win32-2.6\Release\win32\src\PySECURITY_ATTRIBUTES.obj
build\temp.win32-2.6\Release\win32\src\PySECURITY_DESCRIPTOR.obj
build\temp.win32-2.6\Release\win32\src\PySID.obj
build\temp.win32-2.6\Release\win32\src\PyTime.obj
build\temp.win32-2.6\Release\win32\src\PyUnicode.obj
build\temp.win32-2.6\Release\win32\src\PyWAVEFORMATEX.obj
build\temp.win32-2.6\Release\win32\src\PyWinTypesmodule.obj
/OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd
/IMPLIB:build\temp.win32-2.6\Release\win32\src\pywintypes.lib
/MANIFESTFILE:build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest
/MACHINE:x86 /BASE:0x1e7d0000 /DEBUG
/PDB:build\temp.win32-2.6\Release\pywintypes.pdb
   Creating library
build\temp.win32-2.6\Release\win32\src\pywintypes.lib and object
build\temp.win32-2.6\Release\win32\src\pywintypes.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0\bin\mt.exe -nologo
-manifest build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest
-outputresource:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd;2
Unable to import verstamp, no version info will be added
error: can't copy
'build\temp.win32-2.6\Release\win32\src\pywintypes26.lib': doesn't exist
or not a regular file
=========================================================

With 2.6.2 .. this error did not happen.

The file build\temp.win32-2.6\Release\win32\src\pywintypes.lib exists
(but without the version number). 

Was something substantial changed in distutils?

(I am currently investigating this issue; more details will follow)

----------
assignee: tarek
components: Distutils
messages: 93341
nosy: srid, tarek
severity: normal
status: open
title: regression in pywin32 build due to 2.6.3rc1
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 04:21:31 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 02:21:31 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254277291.73.0.974606472957.issue7020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Note the line:

  /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd

In 2.6.2, it was:

  /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes26.dll

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 04:45:26 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Sep 2009 02:45:26 +0000
Subject: [issue6186] test_thread occasionally reports unhandled exceptions on
	OS X
In-Reply-To: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>
Message-ID: <1254278726.3.0.126124901603.issue6186@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also seen on Python 2.6.3rc1.

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6186>
_______________________________________

From report at bugs.python.org  Wed Sep 30 04:55:59 2009
From: report at bugs.python.org (Konstantin M. Khankin)
Date: Wed, 30 Sep 2009 02:55:59 +0000
Subject: [issue7021] subprocess.Popen doesn't work without "executable="
In-Reply-To: <1254279359.58.0.557199390007.issue7021@psf.upfronthosting.co.za>
Message-ID: <1254279359.58.0.557199390007.issue7021@psf.upfronthosting.co.za>


New submission from Konstantin M. Khankin <homecreate at list.ru>:

I'm need to call sendmail. So I wrote:
http://paste.org.ru/?imuoia
os.stat there is to confirm that python can have access to sendmail
executable
That code returned an exception:
http://paste.org.ru/?jbxadp
But documentation says, that I can write executable name with args in
"args=" parameter. But program didn't work until I wrote
"/usr/sbin/sendmail" both in the "executable=" and "args=" parameters

----------
components: Library (Lib)
messages: 93344
nosy: hc
severity: normal
status: open
title: subprocess.Popen doesn't work without "executable="
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7021>
_______________________________________

From report at bugs.python.org  Wed Sep 30 05:16:17 2009
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 30 Sep 2009 03:16:17 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254213352.72.0.338812920874.issue7005@psf.upfronthosting.co.za>
Message-ID: <9cee7ab80909292015x223fb2e8vcb40ab769257a455@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I just looked at some MySQL configuration examples, and wonder if the
guys that made that configuration-style choice were on crack.

MySQL's syntax is sufficient justification for this feature (however
abhorrent I consider it).

(I've not read the patch.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Wed Sep 30 05:17:19 2009
From: report at bugs.python.org (Konstantin M. Khankin)
Date: Wed, 30 Sep 2009 03:17:19 +0000
Subject: [issue7021] subprocess.Popen doesn't work without "executable="
In-Reply-To: <1254279359.58.0.557199390007.issue7021@psf.upfronthosting.co.za>
Message-ID: <1254280639.08.0.290371477175.issue7021@psf.upfronthosting.co.za>


Konstantin M. Khankin <homecreate at list.ru> added the comment:

And I still can't make it works. Now sendmail is called but says that
"Recipient addresses must be specified on the command line or via the -

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7021>
_______________________________________

From report at bugs.python.org  Wed Sep 30 05:24:08 2009
From: report at bugs.python.org (Konstantin M. Khankin)
Date: Wed, 30 Sep 2009 03:24:08 +0000
Subject: [issue7021] subprocess.Popen doesn't work without "executable="
In-Reply-To: <1254279359.58.0.557199390007.issue7021@psf.upfronthosting.co.za>
Message-ID: <1254281048.05.0.501593848751.issue7021@psf.upfronthosting.co.za>


Konstantin M. Khankin <homecreate at list.ru> added the comment:

Sorry, it's my fault. I must write it as list, not as string

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7021>
_______________________________________

From report at bugs.python.org  Wed Sep 30 06:40:42 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Sep 2009 04:40:42 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254285642.73.0.900156372786.issue7020@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Is this a release blocker problem for 2.6.3?

----------
nosy: +barry, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 08:11:11 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Wed, 30 Sep 2009 06:11:11 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254291071.35.0.114325207474.issue6972@psf.upfronthosting.co.za>


Changes by Thomas W. Barr <twb at rice.edu>:


Removed file: http://bugs.python.org/file15002/zipfile-6972-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 08:14:03 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Wed, 30 Sep 2009 06:14:03 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254291243.28.0.179582773603.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

My apologies, I clicked the wrong button and deleted my test. There is no 
change in the newly uploaded one.

----------
Added file: http://bugs.python.org/file15005/zipfile-6972-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 08:19:26 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 06:19:26 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254291566.04.0.554006001923.issue7020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Quite note: I am able to repro this freshly using pywin32 212 version.

http://sourceforge.net/projects/pywin32/files/pywin32/Build%20212/
pywin32-212.zip/download

(214 goes past the copying part, but I could not complete the build to 
some missing executable in Visual C++ installation .. will verify 
tomorrow).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 08:24:23 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 06:24:23 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254291863.52.0.484116597326.issue7020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Replacing the distutils packages with the Lib/distutils from 2.6.2 
fixed the issue. So this was introduced by a change in distutils.

Tarek, any insight into this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 08:50:11 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 30 Sep 2009 06:50:11 +0000
Subject: [issue4192] Subprocess error with I/O redirection to Pipes
In-Reply-To: <1224861800.81.0.399738040895.issue4192@psf.upfronthosting.co.za>
Message-ID: <1254293411.21.0.387371764943.issue4192@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4192>
_______________________________________

From report at bugs.python.org  Wed Sep 30 08:52:42 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 30 Sep 2009 06:52:42 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

*Propositions of doc update*

*RawIOBase*.read(n: int) -> bytes

Read up to n bytes from the object and return them. Fewer than n bytes
may be returned if the operating system call returns fewer than n bytes.
If 0 bytes are returned, and n was not 0, this indicates end of file. If
the object is in non-blocking mode and no bytes are available, the call
returns None.


<warning - this proposition requires patching teh current implementation
as well>:
*RawIOBase*.readinto(b: bytearray, [start: int = None], [end: int =
None]) -> int

start and end are used as slice indexes, so that the bytearray taken
into account is actually range = b[start:end] (or b[start:], b[:end] or
b[:], depending on the arguments which are not None).

Read up to len(range) bytes from the object and store them in b, returning
the number of bytes read. Like .read, fewer than len(range) bytes may be
read, and 0 indicates end of file if len(range) is not 0.
None is returned if a non-blocking object has no bytes available. The
length of b is never changed.

----------
assignee: georg.brandl
components: Documentation, IO
messages: 93352
nosy: georg.brandl, pakal
severity: normal
status: open
title: Doc update for io module
type: feature request
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7022>
_______________________________________

From report at bugs.python.org  Wed Sep 30 11:00:30 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 30 Sep 2009 09:00:30 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254301230.55.0.216940610137.issue7020@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/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 11:23:18 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 30 Sep 2009 09:23:18 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254302598.67.0.269489027935.issue7020@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am investingating in py2exe build_ext custom command and in the
distutils bugfixes that where done, to understand the problem, I'll let
you know as soon as I've found it.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 11:36:53 2009
From: report at bugs.python.org (zengke)
Date: Wed, 30 Sep 2009 09:36:53 +0000
Subject: [issue7023] Marshal doesn't release GIL while dumping
In-Reply-To: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>
Message-ID: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>


New submission from zengke <superisaac.ke at gmail.com>:

If marshal.dumps() is handling a large data, It keeps acquiring the GIL
and may take several seconds, Other threads therefor are blocked.
marshal.loads should also be friendly to other threads.

----------
components: Library (Lib)
files: marshal_threads.patch
keywords: patch
messages: 93354
nosy: zengke
severity: normal
status: open
title: Marshal doesn't release GIL while dumping
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15006/marshal_threads.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7023>
_______________________________________

From report at bugs.python.org  Wed Sep 30 11:39:42 2009
From: report at bugs.python.org (zengke)
Date: Wed, 30 Sep 2009 09:39:42 +0000
Subject: [issue7023] Marshal doesn't release GIL while dumping
In-Reply-To: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>
Message-ID: <1254303582.47.0.582313459142.issue7023@psf.upfronthosting.co.za>


Changes by zengke <superisaac.ke at gmail.com>:


----------
versions: +Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7023>
_______________________________________

From report at bugs.python.org  Wed Sep 30 12:22:41 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 30 Sep 2009 10:22:41 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254306161.97.0.69144435567.issue7020@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Pywin32 is patching "build_ext.get_ext_filename", making the assumption
that it will be called only in a certain way (namespaces names)
by "build_ext.build_extension", to force the name of the output from
"pywintypes.pyd" to "pywintypes.dll".

But this API, even if its doctest doesn't make it clear (I will change
it to make it clearer) is used for both namespaced names and non
namespaced names by the community.

Lately we had a bug with inplace building of namespaced and non
namespaced extensions. To fix it, "build_ext.build_extension" is now
calling "get_ext_filename" differently and when it calls the pywin32
patched version, it fails because pywin32 fails to recognize the
"pywintypes" name and pass it to the non-patched
build_ext.get_ext_filename, leading to the problem.

The fix has to be done on pywin32 side, by making "get_ext_filename"
works as it is supposed : returning an extension name for any filename,
wheter it's namespaced or not.

I can help on it, it's a very simple fix.

But at the end, if pywin32 has to do such patches, there's a problem in
the way distutils plays with the MSVC linker : we should be able to work
with .dll's and .pyd's whithout having to patch build_ext behavior like
this.

----------
resolution: accepted -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 13:26:25 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Sep 2009 11:26:25 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254226562.01.0.0567591205184.issue6992@psf.upfronthosting.co.za>
Message-ID: <d34314100909300426r44e4c3f8v3989b624cf629606@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> The good pratice, if there are several authors, is to setup a
> mailing-list (and put its address as official contact address).

True. Some packages already do this.

> Otherwise collaboration gets inevitably messy, since authors can get
> contacted in private randomly.

People who use Python are usually smart enough to include all authors
in TO or CC field.

> I don't think we should multiply those fields in order to accomodate for
> subtle role differences. Also, I don't think PyPI is the place to record
> detailed attribution information. An ad-hoc CREDITS, ACKS file or
> similar is what you want IMO.

Well, I am writing a plugin and I my framework doesn't parse CREDITS,
ACKS or similar PEP, but it can extract package information to display
my name. I want my name to be displayed by this framework. It is
called Trac.

> What does changing the type of the "author" field make clearer exactly?
> It is a field for human beings to read, and a human being is perfectly
> able to parse "AP <ap at example.com>, Tarek <tarek at example.com>" without
> the help of a computer.

Type of `author` is not changed. It remains a single string that
doesn't include email. New field `authors` is introduced instead. It
can contain a single string with comma-separated authors. It is even
better than list.

> The metadata are completely messy. Users are already confused.

I think it should go into another `parent` ticket with a title like
"Perfection is achieved when there is nothing left to take away". =) I
think that we need to deprecate fields and leave links on their
meaning and how to translate them into other fields in documentation.
After three years everybody (well, at least the major part) will be
happy. Otherwise the frustration continue.

> Any change to the metadata fields will require a PEP 341 change, so
> everyone will be free to do a +1 or a -1.
>
> But saying that making the metadata evolve "is not the way we will make
> Python a reliable platform to use and develop for" is completely
> wrong imho.

+1

> Most of the meta data is parsed by humans, so I don't see any
> complication with adding multiple authors to the author field using
> standard email format: "Anatoli <email at here>, Tarek <email at here>".

Right, but then what author_email field is for? It looks almost
obvious that if author contain list of author names then author_email
should contain list of emails. Especially, when you add another author
to the package where author_email is already used. We should not
forget that developers who are overwhelmed with docs even without
distutils and try to keep rules short and simple.

> A metadata system, by definition, has to remain reasonably stable (or be
> version-numbered, such that old metadata can be recognized properly).
> You can certainly add fields, but replacing existing fields with others
> should be sufficiently motivated.

That's why it should be new `authors` field.

> In order to clear up the inconsistency with maintainer not
> being a possible meta-data field, I think "Maintainer" should
> be added to the meta-data. Dito for "Maintainer-EMail".
>
> Regarding making the meta-data fields multi-valued, you have
> to be aware that when parsing the meta-data using an rfc822
> style module, code assuming that only one Author field
> exists, will return (just) one of the available fields and
> it's not at all clear which.

This quote is totally confusing. Sounds WAY too complicated. If you're
going to switch to meta-discussions I may fall off at some point.

I suspect that there are some meta-internals of Distutils that I must
be aware of as a Python developer, but I just want to add myself to
setup.py along with other developer and learn my framework use this
info fully. Consider this a user-story.

>>> In order to clear up the inconsistency with maintainer
>>> not being a possible meta-data field, I think "Maintainer"
>>> should be added to the meta-data. Dito for "Maintainer-EMail".
>>
>> Do you remember what's the story behind those two fields ?
>
> I don't really remember, but suppose that the field was
> added for cases where a package is being abandoned by the
> original author and then maintained by someone new.

I thought that setup.py metadata format is extensible. Let's leave
`maintainers` extension to the tools that need it, i.e. PyPI. But IIRC
even PyPI doesn't use this field to grant access to package info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 13:50:11 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Sep 2009 11:50:11 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <d34314100909300426r44e4c3f8v3989b624cf629606@mail.gmail.com>
Message-ID: <4AC345EE.6080806@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

anatoly techtonik wrote:
>> What does changing the type of the "author" field make clearer exactly?
>> It is a field for human beings to read, and a human being is perfectly
>> able to parse "AP <ap at example.com>, Tarek <tarek at example.com>" without
>> the help of a computer.
> 
> Type of `author` is not changed. It remains a single string that
> doesn't include email. New field `authors` is introduced instead. It
> can contain a single string with comma-separated authors. It is even
> better than list.

Right, but then we have:

author
author_email
authors
maintainer
maintainer_email

for consitency, we'd also need:

author_emails
maintainers
maintainer_emails

That's even more confusing than what we already have and
it's not needed to solve the use case.

>> Most of the meta data is parsed by humans, so I don't see any
>> complication with adding multiple authors to the author field using
>> standard email format: "Anatoli <email at here>, Tarek <email at here>".
> 
> Right, but then what author_email field is for? 

No idea. I think it was a YAGNI which was not really needed.

>> In order to clear up the inconsistency with maintainer not
>> being a possible meta-data field, I think "Maintainer" should
>> be added to the meta-data. Dito for "Maintainer-EMail".
>>
>> Regarding making the meta-data fields multi-valued, you have
>> to be aware that when parsing the meta-data using an rfc822
>> style module, code assuming that only one Author field
>> exists, will return (just) one of the available fields and
>> it's not at all clear which.
> 
> This quote is totally confusing. Sounds WAY too complicated. If you're
> going to switch to meta-discussions I may fall off at some point.

The first part of the quote should be clear. We need a new
meta-field for the already existing setup() keyword parameters
maintainer and maintainer_email.

The second part is something to consider when switching from
a single value meta-data field to a multi-valued one.

The meta-data file in distutils uses the RFC 822 header format
and the rfc822 (in Python 2.x) provides easy ways of getting
at those headers.

However, if code assumes that there's only one "Author" header,
it will just see the last occurrence of that header in the file.

In summary, all that needs to be done is:

* adding the maintainer headers to the meta-data format
* documenting that multiple authors should use a comma-separated
  list of names (optionally with email addresses) in the author
  field.
* document that the author_email and maintainer_email addresses
  should be used to provide a main contact email address for
  each (e.g. the address of a mailing list)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:11:18 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 30 Sep 2009 12:11:18 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254312678.09.0.74633166396.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> Right, but then we have:
>
> author
> author_email
> authors
> maintainer
> maintainer_email
>
> for consitency, we'd also need:
>
> author_emails
> maintainers
> maintainer_emails

In my mind the "perfect" situation would be just two arguments:

- authors  (goes in Author field - possibly multi-valued)
- contact_email (goes in Contact-email field)

And deprecate the others.

The "maintainer" concept is not on the metadata side, so it's not used
at *all* by the third-party tools or by PyPI.  

Adding it in the metadata adds more confusion imho than deprecate its
usage on Distutils side to stick with a very simple concept:

- a distribution has authors
- a distribution has a contact email.

So I am -1 adding Maintainer/Maintainer-email in the Metadata.

Now for the "Contact-email", it guess it's OK to keep "author_email ->
Author-email", and it's no big deal is "Author" stays singled valued,
as long as it contains all authors names right ?

So at the end, the changes on distutils setup() side would be:

- authors  (goes in Author field - with "," separations )
- contact_email  (goes in Author-email field)
- deprecation of the "author", "author_email", 
  "maintainer" and "mainainer_email" arguments 

So the metadata doesn't change and we have what we want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:20:49 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 30 Sep 2009 12:20:49 +0000
Subject: [issue6186] test_thread occasionally reports unhandled exceptions on
	OS X
In-Reply-To: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>
Message-ID: <1254313249.31.0.169298088749.issue6186@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

and on svn trunk

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6186>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:28:18 2009
From: report at bugs.python.org (Jan Kratochvil)
Date: Wed, 30 Sep 2009 12:28:18 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254313698.3.0.37341921377.issue7015@psf.upfronthosting.co.za>


Changes by Jan Kratochvil <jan.kratochvil at redhat.com>:


----------
nosy: +jankratochvil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:30:36 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Sep 2009 12:30:36 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254312678.09.0.74633166396.issue6992@psf.upfronthosting.co.za>
Message-ID: <4AC34F68.6060907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> So at the end, the changes on distutils setup() side would be:
> 
> - authors  (goes in Author field - with "," separations )
> - contact_email  (goes in Author-email field)
> - deprecation of the "author", "author_email", 
>   "maintainer" and "mainainer_email" arguments 
> 
> So the metadata doesn't change and we have what we want.

-1 on that idea :-)

The meta-data is only used by PyPI and perhaps a handful
of other tools. The setup() keyword parameters OTOH are
used by most packages out there, so any change to these
has to be carefully planned.

Overall, I find the presented use case not really relevant
enough to warrant such a huge change. Even less so, since
there is a solution that works today without any changes.

The addition of the maintainer meta-data field would not
hurt anyone and create more consistency.

The rest is just documenting best practices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:38:09 2009
From: report at bugs.python.org (Jan Kratochvil)
Date: Wed, 30 Sep 2009 12:38:09 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254314289.54.0.961600185947.issue7015@psf.upfronthosting.co.za>


Jan Kratochvil <jan.kratochvil at redhat.com> added the comment:

This patch will make the `modules' command succeeed.
Later requesting the specific `gdb' module will cause:

help> gdb
problem in gdb - <type 'exceptions.AttributeError'>: 'module' object has
no attribute 'Command'

I think this is right in general, a single broken module should not
abort the whole modules traversal.


Another issues is why the `gdb' module fails: It expects the bindings
inside the native `/usr/bin/gdb' process to exist.  Should it just
silently skip its functions if no `/usr/bin/gdb' binding is found?  Or
should these gdb modules be located outside of `/usr/lib*/python2.x'?
There are already some glue python modules
in `/usr/share/gdb/auto-load/'.  Thanks for advice.

----------
keywords: +patch
Added file: http://bugs.python.org/file15007/pkgutil.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:46:57 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Sep 2009 12:46:57 +0000
Subject: [issue7023] Marshal doesn't release GIL while dumping
In-Reply-To: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>
Message-ID: <1254314817.21.0.85897263734.issue7023@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is wrong; the function allows other threads to run while it
calls _PyString_Resize(), this will lead to crashes.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7023>
_______________________________________

From report at bugs.python.org  Wed Sep 30 14:54:15 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 30 Sep 2009 12:54:15 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254315255.41.0.837067032774.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> The meta-data is only used by PyPI and perhaps a handful
> of other tools.
[...]
> The addition of the maintainer meta-data field would 
> not hurt anyone and create more consistency.

since PyPI has its own Role system (owner, maintainer) managed by the
user who registered the distribution, independantly from the Metadata,
what use case are you thinking about for a new Maintainer field ?

When an author is not maintaining a package anymore, and an extra name
has to be added, we previously said that this extra name could be added
in the author field. 

So what would be the gain to distinguish maintainers form authors, and 
how PyPI will deal with the fact that a package will have maintainers in
its metadata, and maintainers at PyPI that may differ ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 15:02:04 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Sep 2009 13:02:04 +0000
Subject: [issue6992] Adding a Contributor field in PEP 314
In-Reply-To: <1254315255.41.0.837067032774.issue6992@psf.upfronthosting.co.za>
Message-ID: <4AC356C8.3000604@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> 
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
>> The meta-data is only used by PyPI and perhaps a handful
>> of other tools.
> [...]
>> The addition of the maintainer meta-data field would 
>> not hurt anyone and create more consistency.
> 
> since PyPI has its own Role system (owner, maintainer) managed by the
> user who registered the distribution, independantly from the Metadata,
> what use case are you thinking about for a new Maintainer field ?

PyPI is just an application using the meta-data - and the only one
I know of.

I'm just suggesting to add the meta-data field in order to recreate
consistency - not advocating that setup() parameter or its use.

> When an author is not maintaining a package anymore, and an extra name
> has to be added, we previously said that this extra name could be added
> in the author field. 
> 
> So what would be the gain to distinguish maintainers form authors, and 
> how PyPI will deal with the fact that a package will have maintainers in
> its metadata, and maintainers at PyPI that may differ ?

That's up for the package owners to sort out. I would expect the
maintainer to do a new release and update the maintainer field.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 15:15:50 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 30 Sep 2009 13:15:50 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254316550.16.0.817669715381.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> I'm just suggesting to add the meta-data field in order to recreate
> consistency - not advocating that setup() parameter or its use.

Yes but fixing this inconsitency can be done on either side:
A - remove the maintainer and maintainer_email 
B - add the Maintainer and Maintainer-email in the metadata

While I understand your PoV about the fact that B/ is not impacting
existing packages and doesn't require any deprecation, I would like to
find some use cases for having such fields in the Metadata, other than
fixing the inconsistency.

If we don't have a use case, I'd go for A/

----------
title: Adding a Contributor field in PEP 314 -> PEP 314 inconsistency (authors/author/maintainer)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Wed Sep 30 16:22:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2009 14:22:44 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254320564.57.0.852482658172.issue7015@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It may well be possible to improve the handling of exceptions (I haven't
looked at your patch yet), but fixing gdb, or rather the python bindings
for it, are out of the scope of this bug tracker since it is third-party
code.

----------
assignee: georg.brandl -> 
components: +Library (Lib) -Documentation
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Wed Sep 30 16:23:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Sep 2009 14:23:06 +0000
Subject: [issue7023] Marshal doesn't release GIL while dumping
In-Reply-To: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>
Message-ID: <1254320586.48.0.591020801909.issue7023@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

In fact, almost no place in marhsal is thread safe, so releasing the GIL
anywhere is not safe.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7023>
_______________________________________

From report at bugs.python.org  Wed Sep 30 16:48:39 2009
From: report at bugs.python.org (Harshad Modi)
Date: Wed, 30 Sep 2009 14:48:39 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>


New submission from Harshad Modi <hmo at tinyerp.com>:

Hi,

I try to open ftp site using webbrowser.open('ftp://localhost:21') in
python2.6.

but It can not open and give error like :
Error showing url: The specified location is not mounted

It is working good in python2.5

so can anybod help me ? what am I wrong ?

Thanks in Adcance.

----------
messages: 93368
nosy: hmo
severity: normal
status: open
title: webbrowser : Could not open ftp server using webbrowser.open()
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7024>
_______________________________________

From report at bugs.python.org  Wed Sep 30 17:19:12 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 30 Sep 2009 15:19:12 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <20090930151855.GA6653@ubuntu.ubuntu-domain>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

It is very difficult to debug with the information you have provided.
The webbrowser.py has indeed undergone some changes, but they are
positive changes and should not break any working behaviour.

For your problem, you might want to mention.
1) Your OS.
2) Your Default Browser ( as set by the OS)
3) Also, do the webbrowser.open() on a generic site like
"ftp://ftp.aduni.org" in your python2.6 installation to see if that
works.

It works for me in python2.6 + firefox 3.x + Ubuntu.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7024>
_______________________________________

From report at bugs.python.org  Wed Sep 30 20:35:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Sep 2009 18:35:37 +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: <1254335737.01.0.378126127915.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A first attempt for lgamma, using Lanczos' formula.

In general, this gives very good accuracy.  As the tests show, there's one 
big problem area, namely when gamma(x) is close to +-1, so that lgamma(x) 
is close to 0.  This happens for x ~ 1.0,  x ~ 2.0, and various negative 
values of x (mathematically, lgamma(x) hits zero twice in each interval 
(n-1, n) for n <= -2).  In that case the accuracy is still good in 
absolute terms (around 1e-15 absolute error), but terrible in ulp terms.

I think it's reasonable to allow an absolute error of a few times the 
machine epsilon in lgamma:  for many uses, the lgamma result will be
exponentiated at some point (often after adding or subtracting other 
lgamma results), and at that point this absolute error just becomes a 
small relative error.

----------
Added file: http://bugs.python.org/file15008/lgamma1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Wed Sep 30 21:20:42 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 19:20:42 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254338442.11.0.573615129085.issue7020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Thank you Tarek.

I was able to fix the issue by patching pywin32's setup.py by using the 
`get_ext_filename` function from the CVS HEAD revision (which handles non-
namespaced extensions as well).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________

From report at bugs.python.org  Wed Sep 30 21:29:51 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Wed, 30 Sep 2009 19:29:51 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254338991.79.0.866017381794.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

os.path.realpath() doesn't normalize case, so this could have issues on
Windows. The new patch should not.

The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive.
That's another bug for another ticket, though.

----------
Added file: http://bugs.python.org/file15009/zipfile-6972-patch-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 21:30:02 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Wed, 30 Sep 2009 19:30:02 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254339002.02.0.520929083719.issue6972@psf.upfronthosting.co.za>


Changes by Thomas W. Barr <twb at rice.edu>:


Removed file: http://bugs.python.org/file15003/zipfile-6972-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 21:36:36 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Sep 2009 19:36:36 +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: <1254339396.09.0.128380163218.issue3366@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I agree with your reasoning.

Any chance of also getting the incomplete beta and gamma functions,
needed to compute the CDF of many commonly used probability
distributions? (Beta, Logarithmic, Poisson, Chi-Square, Gamma, etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Wed Sep 30 22:03:54 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Sep 2009 20:03:54 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254341034.27.0.600477321414.issue6972@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive."

Not so. Case-sensitive vs case-insensitive behavior is chosen when 
initializing an HFS+ file system (since OS X 10.3).

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 22:11:37 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Wed, 30 Sep 2009 20:11:37 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254341497.03.0.53574714172.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Good point, I'd forgotten that case-sensitive file systems are an
option. I do know that it's not the default, though, and that as shipped
from Apple, at least the consumer machines are case-insensitive. Things
may be different in server-land.

For what it's worth, NTFS isn't entirely case-insensitive, either.
(http://support.microsoft.com/kb/100625)

Should the os.path.normcase() method be made smarter, and actually query
the filesystem about such things? (If I should start a new ticket for
this, somebody please let me know.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Wed Sep 30 23:29:42 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Sep 2009 21:29:42 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254346182.98.0.474878586018.issue6972@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Yes, as shipped from the factory, the default "root" file system is 
still case-insensitive but the user can change that.  There there are 
file systems on attached disk images and NFS-mounted file systems, etc 
etc.  More to the point, it's not a system attribute, rather it's a 
file-system attribute and, since a file system mount point can be almost 
anywhere in a directory structure, in general, you can't predict where 
you're going to encounter insensitive vs -sensitive behavior; it could 
vary from directory to directory.  But isn't dealing with case-
insensitive behavior just a special case of the general case of what 
extract/extractall do about overwriting existing files?  I don't see 
that addressed in the current docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________