From report at bugs.python.org  Sat Dec  1 00:00:06 2007
From: report at bugs.python.org (George Notaras)
Date: Fri, 30 Nov 2007 23:00:06 -0000
Subject: [New-bugs-announce] [issue1531] tarfile.open(fileobj=f) and bad
	metadata of the first file within the archive
Message-ID: <1196463606.39.0.826959093922.issue1531@psf.upfronthosting.co.za>


New submission from George Notaras:

Assume the following situation:
- a healthy and uncompressed tar file: a.tar
- the metadata of the 1st and second files within the archive start at
positions 0 and 756 (realistic example values)

I partially damage 200 bytes of metadata (byte range 0-500) of the first
archived file:

f = open("a.tar", "rb+")
f.seek(100)
f.write("0"*200)

Now, I seek to the start of the 2nd archived file's metadata:

f.seek(756)

And I try to open the tar archive using tarfile.open() passing the
previous fileobject to it.

import tarfile
f_tar = tarfile.open(fileobj=f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "tarfile.py", line 1143, in open
    raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully

Wouldn't the expected behaviour be to successfully open the tar archive
at offset 756?

It seems that tarfile.open(fileobj=f) seeks to position 0 of the
fileobject f, fails to read the 1st archived file's metadata and throws
an exception.

----------
components: Extension Modules
messages: 58026
nosy: GeorgeNotaras
severity: normal
status: open
title: tarfile.open(fileobj=f) and bad metadata of the first file within the archive
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531>
__________________________________

From report at bugs.python.org  Sat Dec  1 00:17:23 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 30 Nov 2007 23:17:23 -0000
Subject: [New-bugs-announce] [issue1532] Refleak run of test_tcl fails
Message-ID: <1196464643.1.0.5780121191.issue1532@psf.upfronthosting.co.za>


New submission from Christian Heimes:

$ ./python Lib/test/regrtest.py -R:: test_tcl
test_tcl
beginning 9 repetitions
123456789
test test_tcl failed -- Traceback (most recent call last):
  File "Lib/test/test_tcl.py", line 125, in testLoadTk
    tcl.loadtk()
  File "Lib/lib-tk/Tkinter.py", line 1641, in loadtk
    self.tk.loadtk()
_tkinter.TclError: Calling Tk_Init again after a previous call failed
might deadlock

1 test failed:
    test_tcl

----------
components: Tests
keywords: py3k
messages: 58028
nosy: gvanrossum, tiran
priority: low
severity: normal
status: open
title: Refleak run of test_tcl fails
type: crash
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1532>
__________________________________

From report at bugs.python.org  Sat Dec  1 01:28:10 2007
From: report at bugs.python.org (Robert Bradshaw)
Date: Sat, 01 Dec 2007 00:28:10 -0000
Subject: [New-bugs-announce] [issue1533] Bug in range() function for large
	values
Message-ID: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>


New submission from Robert Bradshaw:

Range accepts arguments coerce-able into ints via __int__, but rejects
arguments coerce-able into longs but to large to fit into an int. 

The problem is in handle_range_longs in bltinmodule.c:1527-1541. If they
type is not an int or long, it should try to make it so before failing
(for consistency with smaller values at least). 

Attached is a file that reproduces this bug.

----------
components: Interpreter Core, Library (Lib)
files: bad_range.py
messages: 58034
nosy: robertwb
severity: normal
status: open
title: Bug in range() function for large values
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8839/bad_range.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad_range.py
Type: application/octet-stream
Size: 236 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071201/8e3e9c22/attachment.obj 

From report at bugs.python.org  Sat Dec  1 02:22:16 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 01 Dec 2007 01:22:16 -0000
Subject: [New-bugs-announce] [issue1534] sys.maxfloat patch
Message-ID: <1196472136.65.0.997837511396.issue1534@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Currently Python has no information about the maximum and minimum value
of a float. The patch adds a dict with all important information to sys:

>>> pprint.pprint(sys.maxfloat)
{'dig': 15,
 'epsilon': 2.2204460492503131e-16,
 'mant_dig': 53,
 'max': 1.7976931348623157e+308,
 'max_10_exp': 308,
 'max_exp': 1024,
 'min': 2.2250738585072014e-308,
 'min_10_exp': -307,
 'min_exp': -1021,
 'radix': 2,
 'rounds': 1}

The patch compiles on Linux and Windows.

----------
components: Interpreter Core
files: trunk_maxfloat.patch
keywords: patch, py3k
messages: 58037
nosy: tiran
priority: normal
severity: normal
status: open
title: sys.maxfloat patch
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8840/trunk_maxfloat.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1534>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_maxfloat.patch
Type: text/x-diff
Size: 1650 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071201/331b7dd6/attachment-0001.patch 

From report at bugs.python.org  Sat Dec  1 14:28:10 2007
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Dec 2007 13:28:10 -0000
Subject: [New-bugs-announce] [issue1535] Rename __builtin__ to builtins
Message-ID: <1196515690.18.0.53572861268.issue1535@psf.upfronthosting.co.za>


New submission from Georg Brandl:

As discussed on python-dev.

----------
assignee: gvanrossum
components: Interpreter Core
files: builtins.diff
messages: 58045
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: Rename __builtin__ to builtins
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8842/builtins.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1535>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: builtins.diff
Type: application/pgp-signature
Size: 64686 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071201/814f33be/attachment-0001.pgp 

From report at bugs.python.org  Sat Dec  1 20:04:21 2007
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 01 Dec 2007 19:04:21 -0000
Subject: [New-bugs-announce] [issue1536] pickle's documentation is severely
	outdated
Message-ID: <1196535861.35.0.87845321139.issue1536@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

The current documentation for the pickle module (and related modules) is
outdated and should be updated. For example, the section "Pickling and
unpickling extension types" [1] is not only confusing, but outright
wrong. For Python 2.6, the documentation of cPickle should be updated to
reflect the differences between the cPickle and pickle.py modules. It
would be also be appropriate to note that cPickle is pending removal and
should not be used anymore.

[1]:
http://docs.python.org/dev/library/pickle.html#pickling-and-unpickling-extension-types

----------
assignee: alexandre.vassalotti
components: Documentation
messages: 58063
nosy: alexandre.vassalotti
priority: normal
severity: normal
status: open
title: pickle's documentation is severely outdated
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1536>
__________________________________

From report at bugs.python.org  Sun Dec  2 08:08:02 2007
From: report at bugs.python.org (Chad Austin)
Date: Sun, 02 Dec 2007 07:08:02 -0000
Subject: [New-bugs-announce] [issue1537] Change GeneratorExit's base class
	from Exception to BaseException
Message-ID: <1196579282.47.0.735370716899.issue1537@psf.upfronthosting.co.za>


New submission from Chad Austin:

Per discussion at http://mail.python.org/pipermail/python-dev/2007-
December/075498.html, this patch changes GeneratorExit's base class 
from Exception to BaseException.

I updated the tests and documentation, but I may have missed any other 
discussion of GeneratorExit in the documentation.  Happy to update the 
patch if there is any feedback.

----------
components: Interpreter Core
files: GeneratorExit-BaseException.patch
messages: 58079
nosy: aegis
severity: normal
status: open
title: Change GeneratorExit's base class from Exception to BaseException
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8850/GeneratorExit-BaseException.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GeneratorExit-BaseException.patch
Type: application/octet-stream
Size: 2032 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071202/e9301afa/attachment.obj 

From report at bugs.python.org  Sun Dec  2 08:51:03 2007
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 02 Dec 2007 07:51:03 -0000
Subject: [New-bugs-announce] [issue1538] Avoid string copy when split char
	doesn't match
Message-ID: <1196581862.98.0.506596232577.issue1538@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

The topic of avoiding string copies in certain string methods came up in 
the
ChiPy list:

  http://mail.python.org/pipermail/chicago/2007-December/002975.html.

The attached patch modifies the split and rsplit implementations to 
avoid
making a copy of self when the split fails to find anything to split on:

    >>> s = "abc def"
    >>> x = s.split(';')
    >>> x[0] is s
    True
    >>> y = s.rsplit('-')
    >>> y[0] is s
    True
    >>> t = "abcdef"
    >>> x = t.split()
    >>> x[0] is t
    True
    >>> y = t.rsplit()
    >>> y[0] is t
    True

All tests pass.  Given that this is just a small optimization I
don't believe any changes to the docs or the existing tests are
necessary.

----------
components: Interpreter Core
files: string-split.patch
keywords: patch
messages: 58081
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Avoid string copy when split char doesn't match
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file8851/string-split.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: string-split.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071202/169ceebb/attachment.txt 

From report at bugs.python.org  Sun Dec  2 15:37:25 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 02 Dec 2007 14:37:25 -0000
Subject: [New-bugs-announce] [issue1539] test_collections: failing refleak
	test
Message-ID: <1196606245.22.0.861738153225.issue1539@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The refleak tests of test_collections are broken. I fear that my changes
to regrtest.py have cause the problem but I don't understand why it's
broken. Can you have a look please?

----------
assignee: gvanrossum
components: Tests
keywords: py3k
messages: 58088
nosy: gvanrossum, tiran
priority: normal
severity: normal
status: open
title: test_collections: failing refleak test
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1539>
__________________________________

From report at bugs.python.org  Sun Dec  2 15:41:56 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 02 Dec 2007 14:41:56 -0000
Subject: [New-bugs-announce] [issue1540] Refleak tests: test_doctest and
	test_gc are failing
Message-ID: <1196606516.14.0.848950318684.issue1540@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I've seen the problem on Windows only. test_doctest fails and the
problem also causes test_gc to fail when it is run after test_doctest.
W/o a prior run of test_doctest test_gc doesn't fail.

File "c:\dev\python\py3k\lib\test\test_doctest.py", line 1570, in
test.test_doct
est.test_debug
Failed example:
    try: doctest.debug_src(s)
    finally: sys.stdin = real_stdin
Expected:
    > <string>(1)<module>()
    (Pdb) next
    12
    --Return--
    > <string>(1)<module>()->None
    (Pdb) print(x)
    12
    (Pdb) continue
Got:
    > c:\dev\python\py3k\lib\io.py(281)__del__()
    -> try:
    (Pdb) next
    > c:\dev\python\py3k\lib\io.py(282)__del__()
    -> self.close()
    (Pdb) print(x)
    *** NameError: NameError("name 'x' is not defined",)
    (Pdb) continue
    12
**********************************************************************
1 items had failures:
   1 of   4 in test.test_doctest.test_debug
***Test Failed*** 1 failures.
test test_doctest failed -- 1 of 418 doctests failed
test_gc
test test_gc failed -- Traceback (most recent call last):
  File "c:\dev\python\py3k\lib\test\test_gc.py", line 193, in test_saveall
    self.assertEqual(gc.garbage, [])
AssertionError: [<io.BytesIO object at 0x01237968>] != []

2 tests failed:
    test_doctest test_gc

----------
components: Tests, Windows
keywords: py3k
messages: 58089
nosy: tiran
priority: normal
severity: normal
status: open
title: Refleak tests: test_doctest and test_gc are failing
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540>
__________________________________

From report at bugs.python.org  Sun Dec  2 18:54:16 2007
From: report at bugs.python.org (billiejoex)
Date: Sun, 02 Dec 2007 17:54:16 -0000
Subject: [New-bugs-announce] [issue1541] Bad OOB data management when using
	asyncore with select.poll()
Message-ID: <1196618056.9.0.300104478176.issue1541@psf.upfronthosting.co.za>


New submission from billiejoex:

asyncore's module readwrite() function, used when invoking
asyncore.loop(use_poll=1), erroneously calls handle_read_event() when
receiving OOB (Out Of Band) data. handle_expt_event() should be called
instead.
The patch in attachment does that.


In addition I strongly think that POLLERR, POLLHUP and POLLNVAL events
handling is incorrect too.
As far as I read from here:
http://www.squarebox.co.uk/cgi-squarebox/manServer/usr/share/man/man0p/poll.h.0p
...they refers to the following events:

POLLERR 	An error has occurred (revents only).
POLLHUP 	Device has been disconnected ( revents only).
POLLNVAL	Invalid fd member (revents only).

They are actually associated to handle_expt_event() and this is
incorrect since it should be called only when receiving OOB data.

        if flags & (select.POLLERR | select.POLLHUP | select.POLLNVAL):
            obj.handle_expt_event()

I'm not sure what should be called instead, if handle_read_event or
handle_read or handle_error.

I tried to take a look at how Twisted manages the thing but it seems
that OOB is not even supported.
Maybe someone with more experience in using select.poll could clarify that.

----------
components: Library (Lib)
files: asyncore.diff
messages: 58093
nosy: billiejoex
severity: normal
status: open
title: Bad OOB data management when using asyncore with select.poll()
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8854/asyncore.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1541>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asyncore.diff
Type: application/octet-stream
Size: 417 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071202/da1ae2ba/attachment.obj 

From report at bugs.python.org  Sun Dec  2 19:59:47 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 02 Dec 2007 18:59:47 -0000
Subject: [New-bugs-announce] [issue1542] Ship 32 and 64bit libs with MSI
	installer
Message-ID: <1196621987.22.0.834586722022.issue1542@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Hello Martin!

How do you like the idea to ship the 32bit and 64bit libs with the MSI
installer? The 64bit libs could be stored in libs64 while the 32bit libs
stay in libs.

I'm working on a task for the GHOP to add cross compiling support to
msvc9compiler. The extra libs are needed to compile 64bit libs on Win32
or the other way around.

Christian

----------
assignee: loewis
components: Installation, Windows
messages: 58094
nosy: loewis, tiran
priority: low
severity: normal
status: open
title: Ship 32 and 64bit libs with MSI installer
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542>
__________________________________

From report at bugs.python.org  Sun Dec  2 20:39:52 2007
From: report at bugs.python.org (Isaul Vargas)
Date: Sun, 02 Dec 2007 19:39:52 -0000
Subject: [New-bugs-announce] [issue1543] MSI installer needs to be updated
	to install x86 and x64 versions of Python on Vista 64 bit
Message-ID: <1196624392.88.0.572306871995.issue1543@psf.upfronthosting.co.za>


New submission from Isaul Vargas:

Problem:
I'd like to run Python 32 bit (for compatibility with extensions) and 
Python 64 bit on Vista (for speed and 64 bit apps) on one machine. 
However Vista has an 'improved' installer for MSI apps, where if I 
install Python 64 bit first, I can't install Python 32 bit afterwards, 
because Vista's Window Installer says 'Another version of this product 
is already installed. Installation of this version cannot continue. To 
configure or remove the existing version of this product, use 
Add/Remove Programs on the Control Panel'

The converse of this is true, if you install Python 64 bit first, you 
cannot install Python 32 bit afterwards.

The MSI packaging needs to be updated.

----------
components: Installation, Windows
messages: 58095
nosy: Dude-X
severity: normal
status: open
title: MSI installer needs to be updated to install x86 and x64 versions of Python on Vista 64 bit
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1543>
__________________________________

From report at bugs.python.org  Mon Dec  3 06:11:27 2007
From: report at bugs.python.org (Daniela)
Date: Mon, 03 Dec 2007 05:11:27 -0000
Subject: [New-bugs-announce] [issue1544] IDLE installation problems and no
	message errors
Message-ID: <1196658687.21.0.152111885524.issue1544@psf.upfronthosting.co.za>


New submission from Daniela:

Installed Python 2.5.1 on windows. Menu is set as it was supposed to,all
the options appear, the command line works perfectly, the IDLE doesn't -
I click on it in the menu and it seems it will start run and then...
nothing. No window pops up, not even a flash, no message errors,
nothing... I've reinstalled many times, 
tried to recover installation, no lucky.

Do any body had the same problem?

----------
components: Installation
messages: 58111
nosy: danicyber
severity: urgent
status: open
title: IDLE installation problems and no message errors
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544>
__________________________________

From report at bugs.python.org  Mon Dec  3 08:08:50 2007
From: report at bugs.python.org (=?utf-8?q?ianar=C3=A9?=)
Date: Mon, 03 Dec 2007 07:08:50 -0000
Subject: [New-bugs-announce] [issue1545] shutil fails when copying to NTFS
	in Linux
Message-ID: <1196665730.42.0.657784597912.issue1545@psf.upfronthosting.co.za>


New submission from ianar?:

When using shutil.copy2 or copytree where the source is on a filesystem
that has octal permissions (ie ext3) and the destination is on an NTFS
partition mounted rw, the operation fails with

OSError: [Errno 1] Operation not permitted


I am attaching a version of shutil.py where this has been worked around
by calling copystat like so:

try:
    copystat(src, dst)
except OSError, (n, str):
    # can't change stats on NTFS partition even if
    # OS supports it
    if n == 1:
        pass
    else:
        raise Error, str

----------
components: Library (Lib)
files: shutil1.py
messages: 58112
nosy: ianare
severity: normal
status: open
title: shutil fails when copying to NTFS in Linux
versions: Python 2.5
Added file: http://bugs.python.org/file8859/shutil1.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1545>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shutil1.py
Type: text/x-python
Size: 6311 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071203/0bdfd0be/attachment-0001.py 

From report at bugs.python.org  Mon Dec  3 11:24:56 2007
From: report at bugs.python.org (Adal Chiriliuc)
Date: Mon, 03 Dec 2007 10:24:56 -0000
Subject: [New-bugs-announce] [issue1546] Win32 Platform SDK conflict
Message-ID: <1196677496.38.0.592975445348.issue1546@psf.upfronthosting.co.za>


New submission from Adal Chiriliuc:

The WRITE_RESTRICTED macro defined in structmember.h (value 4) conflicts
with the WRITE_RESTRICTED macro defined in winnt.h (value 8) in the
newer Win32 Platform SDK (such as the one included in Visual Studio 2008).

It generates a warning and could potentially be dangerous as the two
values are different.

----------
components: Interpreter Core
messages: 58113
nosy: adal
severity: normal
status: open
title: Win32 Platform SDK conflict
type: compile error
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1546>
__________________________________

From report at bugs.python.org  Mon Dec  3 13:52:23 2007
From: report at bugs.python.org (Tim Golden)
Date: Mon, 03 Dec 2007 12:52:23 -0000
Subject: [New-bugs-announce] [issue1547] Minor typos in whatsnew26
Message-ID: <1196686343.74.0.825141682463.issue1547@psf.upfronthosting.co.za>


New submission from Tim Golden:

One typo refers to "from __future__ import generators" in the context of
the with statement.

Later what appears to be an incomplete sentence giving an example of the
__dir__ method.

The patch attached is against r59286 of doc/whatsnew/2.6.rst

----------
components: Documentation
files: whatsnew-r59286.patch
messages: 58118
nosy: tim.golden
severity: normal
status: open
title: Minor typos in whatsnew26
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8861/whatsnew-r59286.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1547>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whatsnew-r59286.patch
Type: text/x-diff
Size: 989 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071203/334e4101/attachment.patch 

From report at bugs.python.org  Mon Dec  3 13:54:29 2007
From: report at bugs.python.org (Tim Golden)
Date: Mon, 03 Dec 2007 12:54:29 -0000
Subject: [New-bugs-announce] [issue1548] Tiny typo in doc\using\cmdline.rst
Message-ID: <1196686469.84.0.00146996546166.issue1548@psf.upfronthosting.co.za>


New submission from Tim Golden:

The tiniest of punctuation typos in using/cmdline.rst. Patch is against
59286 of doc/using/cmdline.rst

----------
components: Documentation
files: doc-using-cmdline-r59286.patch
messages: 58119
nosy: tim.golden
severity: normal
status: open
title: Tiny typo in doc\using\cmdline.rst
versions: Python 2.6
Added file: http://bugs.python.org/file8862/doc-using-cmdline-r59286.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc-using-cmdline-r59286.patch
Type: text/x-diff
Size: 377 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071203/5d27d071/attachment.patch 

From report at bugs.python.org  Mon Dec  3 14:51:31 2007
From: report at bugs.python.org (Thomas Herve)
Date: Mon, 03 Dec 2007 13:51:31 -0000
Subject: [New-bugs-announce] [issue1549] Regression with __hash__ definition
	and rich comparison operators
Message-ID: <1196689891.72.0.237226656542.issue1549@psf.upfronthosting.co.za>


New submission from Thomas Herve:

A new behavior was introduced in r59106 in python trunk, which look
suspicious to me. Basically, every time a class defines a comparison
operator, it's __hash__ method is defined to None. The simple following
example shows it:

>>> class A(object):
...     def __init__(self, b):
...             self.b = b
...     def __cmp__(self, other):
...             if not isinstance(other, A):
...                     return -1
...             return cmp(self.b, other.b)
...
>>> hash(A(2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable


The problematic change is here:
http://svn.python.org/view/python/trunk/Objects/typeobject.c?rev=59106&r1=58032&r2=59106

And mainly the overrides_hash call in inherit_slots.

FWIW, I've encounter the problem because zope.interface is now usable on
trunk.

----------
components: Interpreter Core
messages: 58124
nosy: therve
severity: major
status: open
title: Regression with __hash__ definition and rich comparison operators
type: crash
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1549>
__________________________________

From report at bugs.python.org  Mon Dec  3 17:34:09 2007
From: report at bugs.python.org (Ben Hayden)
Date: Mon, 03 Dec 2007 16:34:09 -0000
Subject: [New-bugs-announce] [issue1550] help('modules') broken by several
	3rd party libraries (svn patch attached)
Message-ID: <1196699649.3.0.798271270482.issue1550@psf.upfronthosting.co.za>


New submission from Ben Hayden:

Instead of listing installed modules, help('modules') prints a "please
wait" message, then a traceback noting that a module raised an exception
during import, then nothing else.
This happens in 2.5 and 2.6a0, but not in 2.4, which apparently doesn't
__import__() EVERY module.
Tested only on Gentoo Linux 2.6.19, but same behavior is probable on
other platforms because pydoc and pkgutil are written in cross-platform
Python.

Prominent 3rd party libraries that break help('modules') include Django,
Pyglet, wxPython, SymPy, and Pypy. Arguably, the bug is in those
libraries, but they have good reasons for their behavior. Also, the Unix
philosophy of forgiving input is a good one. Also, __import__()ing every
module takes a significant run-time hit, especially if libraries compute
eg. configuration.

The patch utilizes a pre-existing hook in pkgutil to simply quietly add
the module to the output. (Long live lambda.)

----------
components: Demos and Tools, Library (Lib)
files: pydocbug.patch
messages: 58131
nosy: benjhayden
severity: minor
status: open
title: help('modules') broken by several 3rd party libraries (svn patch attached)
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8863/pydocbug.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1550>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pydocbug.patch
Type: application/octet-stream
Size: 1328 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071203/dd77e4fc/attachment.obj 

From report at bugs.python.org  Mon Dec  3 22:03:50 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 03 Dec 2007 21:03:50 -0000
Subject: [New-bugs-announce] [issue1551] Port Python/import.c to py3k branch
Message-ID: <1196715830.21.0.540885485829.issue1551@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Dear Nick!

I wasn't able to get your modification to Python/import.c from r59288 to
run. Can you please port the files to py3k yourself? Thanks!

Christian

----------
assignee: ncoghlan
components: Interpreter Core
keywords: py3k
messages: 58155
nosy: ncoghlan, tiran
priority: high
severity: normal
status: open
title: Port Python/import.c to py3k branch
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1551>
__________________________________

From report at bugs.python.org  Tue Dec  4 04:38:15 2007
From: report at bugs.python.org (Takeshi Sone)
Date: Tue, 04 Dec 2007 03:38:15 -0000
Subject: [New-bugs-announce] [issue1552] fromfd() and socketpair() should
	return wrapped sockets
Message-ID: <1196739495.6.0.25894007336.issue1552@psf.upfronthosting.co.za>


New submission from Takeshi Sone:

socket() returns socket object wrapped by Python code, but fromfd() and
socketpair() return raw object. This results in behaviour differences
between sockets.
Attached patch fixes it.

----------
components: Library (Lib)
files: fromfd_sockpair.patch
messages: 58172
nosy: ts1
severity: normal
status: open
title: fromfd() and socketpair() should return wrapped sockets
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8870/fromfd_sockpair.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fromfd_sockpair.patch
Type: text/x-patch
Size: 766 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071204/aa88d592/attachment.bin 

From report at bugs.python.org  Tue Dec  4 06:43:57 2007
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 Dec 2007 05:43:57 -0000
Subject: [New-bugs-announce] [issue1553] An errornous __length_hint__ can
	make list() raise a SystemError
Message-ID: <1196747037.55.0.351183859041.issue1553@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

If an iterator with a __length_hint__ method that returns a negative
integer is passed to list(), a SystemError is raised.

>>> class A:
...     def __iter__(self):
...         return self
...     def __length_hint__(self):
...         return -1
... 
>>> list(A())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: NULL result without error in PyObject_Call

----------
messages: 58176
nosy: alexandre.vassalotti
priority: normal
severity: normal
status: open
title: An errornous __length_hint__ can make list() raise a SystemError
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553>
__________________________________

From report at bugs.python.org  Tue Dec  4 17:02:53 2007
From: report at bugs.python.org (Thomas Herve)
Date: Tue, 04 Dec 2007 16:02:53 -0000
Subject: [New-bugs-announce] [issue1554] [patch] socketmodule cleanups:
	allow the use of keywords in socket functions
Message-ID: <1196784173.07.0.425557098914.issue1554@psf.upfronthosting.co.za>


New submission from Thomas Herve:

I attach a patch where I use PyArg_ParseTupleAndKeywords in socketmodule
where ARGSUSED was mentioned, or removed ARGSUSED if keywords already used.

----------
components: Library (Lib)
files: socket_keywords.diff
messages: 58189
nosy: therve
severity: normal
status: open
title: [patch] socketmodule cleanups: allow the use of keywords in socket functions
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file8873/socket_keywords.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1554>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: socket_keywords.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071204/10deb6de/attachment.txt 

From report at bugs.python.org  Tue Dec  4 18:09:10 2007
From: report at bugs.python.org (Tim Golden)
Date: Tue, 04 Dec 2007 17:09:10 -0000
Subject: [New-bugs-announce] [issue1555] Print-media stylesheet for sphinx
	docs incomplete
Message-ID: <1196788150.41.0.412203150247.issue1555@psf.upfronthosting.co.za>


New submission from Tim Golden:

The print-media stylesheet in the sphinx docs did not completely
eliminate the on-screen layout. The attached patch is against r59327 of
sphinx/style/default.css and has been tested against html, htmlhelp and
web under native Win32.

----------
components: Documentation tools (Sphinx)
files: defaults-r59327.patch
messages: 58193
nosy: tim.golden
severity: minor
status: open
title: Print-media stylesheet for sphinx docs incomplete
versions: Python 3.0
Added file: http://bugs.python.org/file8874/defaults-r59327.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1555>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defaults-r59327.patch
Type: text/x-diff
Size: 434 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071204/fd03fb01/attachment.patch 

From report at bugs.python.org  Wed Dec  5 16:51:17 2007
From: report at bugs.python.org (Hendrik Spiegel)
Date: Wed, 05 Dec 2007 15:51:17 -0000
Subject: [New-bugs-announce] [issue1556] Failure when calling __str__ for
	MIMEBase(message, rfc822) objects
Message-ID: <1196869876.98.0.0449623543334.issue1556@psf.upfronthosting.co.za>


New submission from Hendrik Spiegel:

When creating a MIMEBase object with message/rfc822 mimetype invoking
the objects __str__ method results in an exception. 
Even if this behaviour should be intended the error message "TypeError:
Expected list, got <type 'str'>" is not helpful. 
To reproduce the problem run the attached script after creating the file
 'test.eml' in the script's directory.


    mimetype = mimetypes.guess_type(filename)[0]
    maintype, subtype = mimetype.split('/')
    attachment = MIMEBase(maintype, subtype)
    attachment.set_payload(file(filename).read( ))
    print attachment

#python MimebaseError.py                                               
                                                                       
             [1]
message/rfc822
Traceback (most recent call last):
  File "MimebaseError.py", line 19, in <module>
    main()
  File "MimebaseError.py", line 16, in main
    print attachment
  File "email/message.py", line 116, in __str__
  File "email/message.py", line 131, in as_string
  File "email/generator.py", line 84, in flatten
  File "email/generator.py", line 109, in _write
  File "email/generator.py", line 135, in _dispatch
  File "email/generator.py", line 266, in _handle_message
  File "email/message.py", line 185, in get_payload
TypeError: Expected list, got <type 'str'>

----------
components: Library (Lib)
files: MimebaseError.py
messages: 58216
nosy: hsp
severity: normal
status: open
title: Failure when calling __str__ for MIMEBase(message, rfc822) objects
type: crash
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file8879/MimebaseError.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1556>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MimebaseError.py
Type: text/x-python
Size: 468 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071205/6b66baf8/attachment.py 

From report at bugs.python.org  Wed Dec  5 17:46:49 2007
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 05 Dec 2007 16:46:49 -0000
Subject: [New-bugs-announce] [issue1557] import distutils.msvccompiler hangs
	when the environment is too large
Message-ID: <1196873209.5.0.467149777099.issue1557@psf.upfronthosting.co.za>


New submission from Thomas Heller:

'Python -c "import distutils.msvccompiler"' hangs when the environment
is too large.  This is because in Lib\distutils\msvc9compiler.py, line
258, popen.wait() does not return because the subprocess does not
terminate (probably because the stdout buffersize is too small).  This
causes the win64-buildbot to hang.

----------
components: Distutils, Windows
keywords: py3k
messages: 58217
nosy: theller
severity: urgent
status: open
title: import distutils.msvccompiler hangs when the environment is too large
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1557>
__________________________________

From report at bugs.python.org  Wed Dec  5 19:28:26 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 05 Dec 2007 18:28:26 -0000
Subject: [New-bugs-announce] [issue1558] x64 platform doesn't define _WIN64
Message-ID: <1196879306.07.0.906427134352.issue1558@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In VS 2008 the x64 platform doesn't define the _WIN64 macro. The _WIN64
macro defines the MS_WIN64 macro which sets several other macros and
changes some variables in pyconfig.h.

Question: Should we enforce MS_WIN64 for the x64 platform although
_WIN64 is not defined?
Question 2: WHY THE H... is the _WIN64 macro not defined? I'm googling now.

----------
components: Interpreter Core
keywords: 64bit, py3k
messages: 58224
nosy: loewis, mhammond, tiran
priority: urgent
severity: urgent
status: open
title: x64 platform doesn't define _WIN64
type: compile error
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1558>
__________________________________

From report at bugs.python.org  Wed Dec  5 20:58:11 2007
From: report at bugs.python.org (travelgirl)
Date: Wed, 05 Dec 2007 19:58:11 -0000
Subject: [New-bugs-announce] [issue1559] round() does not
Message-ID: <1196884691.56.0.617857445117.issue1559@psf.upfronthosting.co.za>


New submission from travelgirl:

http://docs.python.org/tut/node5.html states, as an example, round(_, 2)
should round to the second decimal place.  makes sense.  when i
attempted it with different numbers, round() returned what looks like a
binary-coded decimal error (see the jpg enclosed), and did not return
just two digits, but 15 digits.  the same error was produced for
round(_, 3).  when the number was changed to 1 digit, the return result
rounded from another direction.

i'd guess this isn't a feature :)

----------
components: Windows
files: python bug.jpg
messages: 58225
nosy: travelgirl
severity: normal
status: open
title: round() does not
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8882/python bug.jpg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python bug.jpg
Type: image/jpeg
Size: 11810 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071205/25f720ab/attachment.jpg 

From report at bugs.python.org  Wed Dec  5 22:00:25 2007
From: report at bugs.python.org (Neil Toronto)
Date: Wed, 05 Dec 2007 21:00:25 -0000
Subject: [New-bugs-announce] [issue1560] PATCH: Attribute lookup caching
Message-ID: <1196888425.03.0.368488878757.issue1560@psf.upfronthosting.co.za>


New submission from Neil Toronto:

I've attached a patch to accelerate type and instance lookups using a
specialized cache. It includes a benchmarking script (fastattr_test.py)
that tests both successful and failing lookups on list, dict and tuple,
and a simple, deep hierarchy. Benchmark results are here:

http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIUpTm6QSG2gZg&hl=en_US

Everything tested in fastattr_test.py is faster except list.__init__ and
list().__init__ (and I haven't got a clue why, so some pointers would be
nice). Pybench is faster overall. TryRaiseExcept is faster for some
non-obvious reason. CreateNewInstances is a little slower, which I'll
discuss in a bit. Setting type attributes is slower, but I haven't
benchmarked that yet. It may not happen often enough that we care as
long as it's not noticeably slow in general usage.

In benchmarks the patch does a little slower, it may be in part because
I removed a manually inlined _PyType_Lookup from
PyObject_GenericGetAttr. Something like it can be put back if it needs
to be.

It works in a fairly obvious way. Every type has a tp_cache, which is a
custom dict type that caches the first value in a type dict in the MRO
for a given name. Lazy cached lookups are done via
_PyType_CachingLookup, which is a drop-in replacement for
_PyType_Lookup. The only way to set an attribute on a type is via its
setattr, so type's setattr notifies subclasses to invalidate specific
cache entries.

The cache dict is custom for two reasons:

1. The regular dict is a little slower because it's more general. The
custom dict is restricted to string-exact keys (types fall back to no
caching if this constraint is violated). Because it's internal to
typeobject.c, it's safe for lookups to return entry pointers rather than
values, so lookups only have to be done once, even on cache misses.

2. Caching missing attributes is crucial for speed on instance attribute
lookups. Both type and metatype instances check all the way through the
MRO for a descriptor before even trying to find an attribute. It's
usually missing. Having to go through the cache machinery to find a
missing attribute for every attribute lookup is expensive. However,
storing all missing attribute queries in the cache is bad - it can grow
unboundedly through hasattr(inst, <random name>) calls.

What's needed is a dict that knows that some of its entries are
transient and doesn't copy them over on resize. It wasn't clear how to
implement that efficiently with a regular dict (I suspect it's not
possible), so I created a new dict type that considers entries transient
(meaning the attribute is missing) when me_value == NULL.

This is also very good for failing hasattr(...) calls and
try...inst.method()...except style duck typing.

Now, about the CreateNewInstances benchmark. It creates three classes
with __init__ methods that assign a few attributes. The missing
descriptors are cached, and then the cache is resized, which clears the
cached missing descriptors. Increasing the minimum cache size from 4 to
8 clears up the problem. However, for any class, SOME minimum cache size
will properly cache missing descriptors and some other one won't.

I have some solutions for this floating around in my head, which I'll
try shortly. (One idea is for missing attributes, if they're not missing
on the *instance*, to be permanent in the cache.) But I'd like to get
this patch off my hard drive and into other people's hands for testing,
poking, prodding, and getting feedback on what's going right and what's not.

----------
components: Interpreter Core
files: fastattr-0.patch.txt
messages: 58229
nosy: ntoronto
severity: normal
status: open
title: PATCH: Attribute lookup caching
versions: Python 2.6
Added file: http://bugs.python.org/file8883/fastattr-0.patch.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1560>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fastattr-0.patch.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071205/28a5d827/attachment-0001.txt 

From report at bugs.python.org  Thu Dec  6 11:38:12 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Dec 2007 10:38:12 -0000
Subject: [New-bugs-announce] [issue1561] py3k: test_mailbox fails on Windows
Message-ID: <1196937492.24.0.0620025474702.issue1561@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

test_mailbox keeps failing on Windows, due to line-ending issues.
Difficult things began when the files started to open in text mode.

Trying to list problems:
- mailbox.py works with differences of tell() results, and uses this to
as an argument to read(). This is wrong for two reasons: tell() returns
an offset in the file, and mixes this with the codec status.
- _PartialFile (a narrowed view of a file) does not work, for the same
kinds of reasons.

----------
components: Windows
messages: 58238
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: test_mailbox fails on Windows
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1561>
__________________________________

From report at bugs.python.org  Thu Dec  6 15:13:37 2007
From: report at bugs.python.org (poelzi)
Date: Thu, 06 Dec 2007 14:13:37 -0000
Subject: [New-bugs-announce] [issue1562] Decimal can't be subclassed useful
Message-ID: <1196950417.92.0.75484555157.issue1562@psf.upfronthosting.co.za>


New submission from poelzi:

The Decimal class doesn't use lookups through self to construct results 
in functions like __add__ to generate the resulting object. This makes 
subclassing Decimal more or less senseless since all methods have to be 
wrapped instead of overriding the __new__ and __init__ methods, which 
could be enough for immutable type.
Currently I'm implementing a Money class which is more or less a 
Decimal with addition currency information. Because resulting Types 
generated with something like return Decimal(something) instead of 
self.__new__(...)

----------
components: Library (Lib)
messages: 58241
nosy: poelzi
severity: normal
status: open
title: Decimal can't be subclassed useful
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1562>
__________________________________

From report at bugs.python.org  Thu Dec  6 19:50:51 2007
From: report at bugs.python.org (Daniel Arbuckle)
Date: Thu, 06 Dec 2007 18:50:51 -0000
Subject: [New-bugs-announce] [issue1563] asyncore and asynchat incompatible
	with Py3k str and bytes
Message-ID: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>


New submission from Daniel Arbuckle:

djarb at highenergymagic.org is working up a patch for this.

----------
components: Library (Lib)
messages: 58251
nosy: djarb
severity: normal
status: open
title: asyncore and asynchat incompatible with Py3k str and bytes
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
__________________________________

From report at bugs.python.org  Thu Dec  6 22:19:11 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Dec 2007 21:19:11 -0000
Subject: [New-bugs-announce] [issue1564] The set implementation should
	special-case PyUnicode instead of PyString
Message-ID: <1196975951.77.0.484974834698.issue1564@psf.upfronthosting.co.za>


Changes by Guido van Rossum:


----------
keywords: py3k
nosy: gvanrossum
severity: normal
status: open
title: The set implementation should special-case PyUnicode instead of PyString
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1564>
__________________________________

From report at bugs.python.org  Fri Dec  7 10:30:33 2007
From: report at bugs.python.org (Shlomo Anglister)
Date: Fri, 07 Dec 2007 09:30:33 -0000
Subject: [New-bugs-announce] [issue1565] round(x,
	y) doesn't behave as expected, round error
Message-ID: <1197019833.36.0.152009860011.issue1565@psf.upfronthosting.co.za>


New submission from Shlomo Anglister:

#Round is unexpectedly wrong
>>> z = complex(1,1)
>>> s=abs(z)
>>> round(s,2)
1.4099999999999999

----------
components: Interpreter Core
messages: 58266
nosy: shlomoa
severity: normal
status: open
title: round(x,y) doesn't behave as expected, round error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565>
__________________________________

From report at bugs.python.org  Fri Dec  7 12:49:59 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Dec 2007 11:49:59 -0000
Subject: [New-bugs-announce] [issue1566] sock_type doesn't have GC although
	it can contain a PyObject*
Message-ID: <1197028199.63.0.287230358639.issue1566@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The socket object is defined in socketmodule.h as

typedef struct {
        PyObject_HEAD
        SOCKET_T sock_fd;       /* Socket file descriptor */
        int sock_family;        /* Address family, e.g., AF_INET */
        int sock_type;          /* Socket type, e.g., SOCK_STREAM */
        int sock_proto;         /* Protocol type, usually 0 */
        PyObject *(*errorhandler)(void); /* Error handler; checks
                                            errno, returns NULL and
                                            sets a Python exception */
        double sock_timeout;             /* Operation timeout in seconds;
                                            0.0 means non-blocking */
} PySocketSockObject;

The PyTypeObject sock_type doesn't have support for cyclic GC. Shouldn't
types that can contain a PyObject* use GC?

----------
components: Extension Modules
messages: 58270
nosy: tiran
priority: normal
severity: normal
status: open
title: sock_type doesn't have GC although it can contain a PyObject*
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1566>
__________________________________

From report at bugs.python.org  Fri Dec  7 14:24:04 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Dec 2007 13:24:04 -0000
Subject: [New-bugs-announce] [issue1567] Patch for new API method
	_PyImport_ImportModuleNoLock(char *name)
Message-ID: <1197033844.22.0.578664150346.issue1567@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch adds a new API method _PyImport_ImportModuleNoLock(const char
*name). It works mostly like PyImport_ImportModule except it does not
block. It tries to fetch the module from sys.modules first and falls
back to PyImport_ImportModule UNLESS the import lock is held by another
thread.

It fixes several issues related to dead locks when a thread uses a
function that imports a module but another thread holds the lock. It
doesn't require static caching of modules.

The patch is against py3k but I can backport it to 2.6.

----------
files: import_nolock.diff
messages: 58272
nosy: gvanrossum, tiran
priority: normal
severity: normal
status: open
title: Patch for new API method _PyImport_ImportModuleNoLock(char *name)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8888/import_nolock.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1567>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: import_nolock.diff
Type: text/x-diff
Size: 13547 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071207/6df69264/attachment.diff 

From report at bugs.python.org  Fri Dec  7 14:28:17 2007
From: report at bugs.python.org (Neil Toronto)
Date: Fri, 07 Dec 2007 13:28:17 -0000
Subject: [New-bugs-announce] [issue1568] PATCH: Armin's attribute lookup
	caching for 3.0
Message-ID: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za>


New submission from Neil Toronto:

This is a half-port of the patches in #1685986 and #1700288 to Python
3.0. Speedups are about the same as in those patches applied to their
respective Python versions for minibenchmarks (included in the patch as
fastattr_test_py3k.py): 5%-30% or more depending on how deep the class
hierarchy is. Pybench takes 4% less time on my system, and pystone takes
6% less time.

(Pybench would do better, but SpecialClassAttribute runs long and spends
half its time setting class attributes.)

The main difference between this and the previous patches is that 3.0's
simplifications allow a smaller footprint and make it easier to analyze
its correctness. Specifically, the fact that every object in the MRO
must be a type allows us to assume that every attribute lookup is
cacheable, and allows integration into the update_subclasses mechanism
when attributes are set. The lack of compiled extension modules means
there is no flag to check to see whether a type object supports caching.

----------
components: Interpreter Core
files: python30-attrcache.diff
messages: 58274
nosy: ntoronto
severity: normal
status: open
title: PATCH: Armin's attribute lookup caching for 3.0
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8889/python30-attrcache.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1568>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python30-attrcache.diff
Type: text/x-patch
Size: 20964 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071207/2318f032/attachment-0001.bin 

From report at bugs.python.org  Fri Dec  7 19:25:27 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Dec 2007 18:25:27 -0000
Subject: [New-bugs-announce] [issue1569] Add VS CRT redist to the MSI
	installer
Message-ID: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The 3.0a2 installer requires the user to install the VS CRT library
manually. 3.0a3 and 2.6a1 should automate the installation of vsredist
somehow.

----------
components: Installation, Windows
keywords: py3k
messages: 58278
nosy: jorend, loewis, tiran
priority: high
severity: normal
status: open
title: Add VS CRT redist to the MSI installer
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Fri Dec  7 20:21:51 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Dec 2007 19:21:51 -0000
Subject: [New-bugs-announce] [issue1570] Backport sys.maxsize to Python 2.6
Message-ID: <1197055311.38.0.952230313311.issue1570@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Reminder for me and myself

----------
assignee: tiran
components: Interpreter Core
messages: 58279
nosy: tiran
priority: high
severity: normal
status: open
title: Backport sys.maxsize to Python 2.6
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1570>
__________________________________

From report at bugs.python.org  Sat Dec  8 13:49:37 2007
From: report at bugs.python.org (Ori Avtalion)
Date: Sat, 08 Dec 2007 12:49:37 -0000
Subject: [New-bugs-announce] [issue1571] Better description of 'L' repr
	removal in "What's New"
Message-ID: <1197118177.63.0.3878516281.issue1571@psf.upfronthosting.co.za>


New submission from Ori Avtalion:

The "common stumbling blocks" section reads:

* Code that unconditionally strips the trailing ``L`` from the
``repr()`` of a long integer will chop off the last digit instead.


This explains a problem and a fix without any reason (one has to guess
it from context).
It should first mention that the 'L' is no longer displayed.

----------
components: Documentation
messages: 58293
nosy: salty-horse
severity: minor
status: open
title: Better description of 'L' repr removal in "What's New"
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571>
__________________________________

From report at bugs.python.org  Sat Dec  8 17:12:05 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 08 Dec 2007 16:12:05 -0000
Subject: [New-bugs-announce] [issue1572] 404 report of SimpleXMLRPCServer is
	broken
Message-ID: <1197130325.35.0.851188581125.issue1572@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Exception happened during processing of request from ('127.0.0.1', 55017)
Traceback (most recent call last):
  File "/home/heimes/dev/python/py3k/Lib/SocketServer.py", line 222, in
handle_request
    self.process_request(request, client_address)
  File "/home/heimes/dev/python/py3k/Lib/SocketServer.py", line 241, in
process_request
    self.finish_request(request, client_address)
  File "/home/heimes/dev/python/py3k/Lib/SocketServer.py", line 254, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/heimes/dev/python/py3k/Lib/SocketServer.py", line 522, in
__init__
    self.handle()
  File "/home/heimes/dev/python/py3k/Lib/BaseHTTPServer.py", line 330,
in handle
    self.handle_one_request()
  File "/home/heimes/dev/python/py3k/Lib/BaseHTTPServer.py", line 324,
in handle_one_request
    method()
  File "/home/heimes/dev/python/py3k/Lib/SimpleXMLRPCServer.py", line
430, in do_POST
    self.report_404()
  File "/home/heimes/dev/python/py3k/Lib/SimpleXMLRPCServer.py", line
486, in report_404
    self.wfile.write(response)
  File "/home/heimes/dev/python/py3k/Lib/socket.py", line 220, in write
    return self._sock.send(b)
TypeError: send() argument 1 must be bytes or read-only buffer, not str
----------------------------------------

After I altered the response to bytes:

  File "/home/heimes/dev/python/py3k/Lib/SimpleXMLRPCServer.py", line
430, in do_POST
    self.report_404()
  File "/home/heimes/dev/python/py3k/Lib/SimpleXMLRPCServer.py", line
489, in report_404
    self.connection.shutdown(0)
socket.error: [Errno 107] Transport endpoint is not connected
----------------------------------------

----------
components: Library (Lib)
keywords: py3k
messages: 58296
nosy: tiran
priority: normal
severity: normal
status: open
title: 404 report of SimpleXMLRPCServer is broken
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1572>
__________________________________

From report at bugs.python.org  Sat Dec  8 19:13:57 2007
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 08 Dec 2007 18:13:57 -0000
Subject: [New-bugs-announce] [issue1573] Improper use of the keyword-only
	syntax makes the parser crash
Message-ID: <1197137637.06.0.398466003336.issue1573@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

I found that the parser fails to handle correctly the (incorrect) case
where the single-star (*), used for delimiting keyword-only arguments,
is immediately followed by a **keywords parameter:

>>> def f(*, **kw):
...   pass
... 
python: Python/ast.c:652: handle_keywordonly_args: Assertion `kwonlyargs
!= ((void *)0)' failed.
[1]    7872 abort (core dumped)  ./python

----------
components: Interpreter Core
keywords: py3k
messages: 58299
nosy: alexandre.vassalotti
severity: normal
status: open
title: Improper use of the keyword-only syntax makes the parser crash
type: crash

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1573>
__________________________________

From report at bugs.python.org  Sun Dec  9 05:36:36 2007
From: report at bugs.python.org (Puneet Arora)
Date: Sun, 09 Dec 2007 04:36:36 -0000
Subject: [New-bugs-announce] [issue1574] Touchpad 2 Finger scroll does not
	work in IDLE on Mac (But scroll wheel of external mouse does)
Message-ID: <1197174996.26.0.961617468565.issue1574@psf.upfronthosting.co.za>


Changes by Puneet Arora:


----------
components: IDLE
nosy: arorap
severity: normal
status: open
title: Touchpad 2 Finger scroll does not work in IDLE on Mac (But scroll wheel of external mouse does)
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574>
__________________________________

From report at bugs.python.org  Sun Dec  9 05:54:56 2007
From: report at bugs.python.org (Andrew Dalke)
Date: Sun, 09 Dec 2007 04:54:56 -0000
Subject: [New-bugs-announce] [issue1575] typo in README
Message-ID: <1197176096.61.0.93336652493.issue1575@psf.upfronthosting.co.za>


New submission from Andrew Dalke:

Current text in README:

        See Mac/OSX/README for more information on framework and 
        universal builds.

Should be

        See Mac/README for more information on framework and 
        universal builds.

because r46719 moved Mac/OSX/* one level up (7 Jun 2006) but didn't 
change this line of the README to reflect the change.

I thought I had commit privs still from summer 2006 to be able to change 
this myself, but something happened in my setup and I haven't tracked 
down the problem...

----------
components: Documentation
files: README.patch
messages: 58314
nosy: dalke
severity: minor
status: open
title: typo in README
versions: Python 2.6
Added file: http://bugs.python.org/file8897/README.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1575>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: README.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071209/3dfd3377/attachment.txt 

From report at bugs.python.org  Sun Dec  9 21:04:21 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Dec 2007 20:04:21 -0000
Subject: [New-bugs-announce] [issue1576] First draft of a post import hook
Message-ID: <1197230661.71.0.762361261009.issue1576@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I've written a rough draft for a post import hook as discussed on the
python 3000 mailing list. The implementation is far from perfect. It
requires more unit tests, a code review and reference count checks.

----------
assignee: tiran
components: Interpreter Core
files: py3k_post_import_hook.patch
keywords: py3k
messages: 58323
nosy: ncoghlan, pje, tiran
priority: normal
severity: normal
status: open
title: First draft of a post import hook
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8900/py3k_post_import_hook.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1576>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_post_import_hook.patch
Type: text/x-diff
Size: 9533 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071209/239113db/attachment.patch 

From report at bugs.python.org  Mon Dec 10 00:23:25 2007
From: report at bugs.python.org (Ingemar Nilsson)
Date: Sun, 09 Dec 2007 23:23:25 -0000
Subject: [New-bugs-announce] [issue1577] shutil.move() does not use
	os.rename() if dst is a directory
Message-ID: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za>


New submission from Ingemar Nilsson:

If you use shutil.move(src, dst) to move a file src to a directory dst,
the file will not be renamed into the dst directory, but rather
copied-then-removed, even if src and dst is on the same filesystem.
There are several ways to fix this:

* (The easiest) Fix the documentation for shutil.move() so that this is
mentioned.
* Fix shutil.move() so that it rename a file into a new directory.
* Change os.rename() to accept a directory as a destination for a file.

The reason for this problem is that shutil.move() tries to use
os.rename(), but fails since the destination is a directory. It then
proceeds to the copy-then-remove method, even though the documentation
gives the impression that this only happens when src and dst are on
different filesystems.

----------
components: Library (Lib)
messages: 58332
nosy: init
severity: normal
status: open
title: shutil.move() does not use os.rename() if dst is a directory
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1577>
__________________________________

From report at bugs.python.org  Mon Dec 10 03:50:27 2007
From: report at bugs.python.org (vizcayno)
Date: Mon, 10 Dec 2007 02:50:27 -0000
Subject: [New-bugs-announce] [issue1578] Problems in win_getpass
Message-ID: <1197255027.05.0.0200043549061.issue1578@psf.upfronthosting.co.za>


New submission from vizcayno:

.python
Python 3.0a2 (r30a2:59397:59399, Dec  6 2007, 22:34:52) [MSC v.1500 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import getpass
>>> clave = getpass.getpass('PASSWD= ').strip().upper()
PASSWD= Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python30\lib\getpass.py", line 63, in win_getpass
    pw = pw + c
TypeError: Can't convert 'bytes' object to str implicitly
>>>
 I get the error when I try to type the first letter of a password.

----------
components: Windows
messages: 58338
nosy: vizcayno
severity: normal
status: open
title: Problems in win_getpass
type: crash
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578>
__________________________________

From report at bugs.python.org  Mon Dec 10 16:23:14 2007
From: report at bugs.python.org (Kylotan)
Date: Mon, 10 Dec 2007 15:23:14 -0000
Subject: [New-bugs-announce] [issue1579] logging documentation is unclear
Message-ID: <1197300194.46.0.863908405505.issue1579@psf.upfronthosting.co.za>


New submission from Kylotan:

The documentation for the logging module is quite confusing, and (I am
told) seems to assume prior experience with the log4j utility or similar.

In particular:
 - the front page has a rather confusing example of the named hierarchy
system, which might mislead the reader by making them think it's about
file types (perhaps for log output) rather than just arbitrary naming
conventions.
 - section 14.5.3 attempts to explain this hierarchy, but does so via an
example for something else (ie. showing logging to multiple
destinations), and is just a large code-dump, mixing several concepts in
one example.

All in all, it could just do with being a lot more explicit about how
the naming convention and the hierarchy works, how each logger relates
to children/parents, and having a more transparent example on the first
page.

----------
components: Documentation
messages: 58347
nosy: Kylotan
severity: normal
status: open
title: logging documentation is unclear
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1579>
__________________________________

From report at bugs.python.org  Mon Dec 10 20:13:27 2007
From: report at bugs.python.org (Noam Raphael)
Date: Mon, 10 Dec 2007 19:13:27 -0000
Subject: [New-bugs-announce] [issue1580] Use shorter float repr when possible
Message-ID: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>


New submission from Noam Raphael:

The current float repr() always calculates the 17 first digits of the
decimal representation of a float, and displays all of them (discarding
trailing zeros). This is a simple method for making sure that
eval(repr(f)) == f. However, many times it results in a long string,
where a shorter string would have sufficed. For example, currently
repr(1.1) is '1.1000000000000001', where obviously '1.1' would have been
good enough, and much easier to read.

This patch implements an algorithm for finding the shortest string that
will evaluate to the right number. It is based on the code from
http://www.cs.indiana.edu/~burger/fp/index.html, and also on the
floating-point formatting function of TCL, Tcl_PrintDouble.

The patch also adds a test case, which takes a long list of floating
point numbers, created especially for testing binary to decimal
conversion, and makes sure that eval(repr(f)) == f. See
floating_points.txt for the source of the list.

----------
components: Interpreter Core
files: short_float_repr.diff
messages: 58359
nosy: noam
severity: normal
status: open
title: Use shorter float repr when possible
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8910/short_float_repr.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: short_float_repr.diff
Type: text/x-patch
Size: 35017 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071210/9e2c6095/attachment-0001.bin 

From report at bugs.python.org  Mon Dec 10 20:41:26 2007
From: report at bugs.python.org (Andreas Hasenack)
Date: Mon, 10 Dec 2007 19:41:26 -0000
Subject: [New-bugs-announce] [issue1581] xmlrpclib.ServerProxy() doesn't use
	x509 data
Message-ID: <1197315686.07.0.947605571907.issue1581@psf.upfronthosting.co.za>


New submission from Andreas Hasenack:

I was trying to use xmlrpclib.ServerProxy() with https and client
certificate validation (I know httplib doesn't do server certificate
validation yet). I found no way to pass on host/uri as a
(host,x509_dict) tuple as the connection methods support, so I came up
with this patch.

----------
components: Library (Lib)
files: xmlrpclib-x509.patch
messages: 58363
nosy: ahasenack
severity: minor
status: open
title: xmlrpclib.ServerProxy() doesn't use x509 data
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8911/xmlrpclib-x509.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmlrpclib-x509.patch
Type: text/x-patch
Size: 1461 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071210/a71a93e1/attachment.bin 

From report at bugs.python.org  Mon Dec 10 21:47:12 2007
From: report at bugs.python.org (Mark Russell)
Date: Mon, 10 Dec 2007 20:47:12 -0000
Subject: [New-bugs-announce] [issue1582] Documentation patch for reversed()
	and __reversed__()
Message-ID: <1197319632.69.0.696110085185.issue1582@psf.upfronthosting.co.za>


New submission from Mark Russell:

This patch adds documentation for the reversed() builtin and 
__reversed__() special method.

----------
components: Documentation
files: reverse-2.6-docs.diff
messages: 58369
nosy: mark_t_russell
severity: normal
status: open
title: Documentation patch for reversed() and __reversed__()
versions: Python 2.6
Added file: http://bugs.python.org/file8912/reverse-2.6-docs.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1582>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: reverse-2.6-docs.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071210/f8355c5f/attachment.txt 

From report at bugs.python.org  Tue Dec 11 00:20:05 2007
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 10 Dec 2007 23:20:05 -0000
Subject: [New-bugs-announce] [issue1583] Patch for signal.set_wakeup_fd
Message-ID: <1197328805.69.0.0206473945829.issue1583@psf.upfronthosting.co.za>


New submission from Adam Olsen:

This adds signal.set_wakeup_fd(fd), which allows a single library to be
woken when a signal comes in.

----------
files: python2.6-set_wakeup_fd1.diff
messages: 58385
nosy: rhamphoryncus
severity: normal
status: open
title: Patch for signal.set_wakeup_fd
Added file: http://bugs.python.org/file8915/python2.6-set_wakeup_fd1.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1583>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python2.6-set_wakeup_fd1.diff
Type: text/x-patch
Size: 4549 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071210/3369bf1d/attachment.bin 

From report at bugs.python.org  Tue Dec 11 05:04:58 2007
From: report at bugs.python.org (C. E. Ball)
Date: Tue, 11 Dec 2007 04:04:58 -0000
Subject: [New-bugs-announce] [issue1584] Mac OS X: building with X11 Tkinter
Message-ID: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>


New submission from C. E. Ball:

On OS X, I wanted to build my own copy of Python that used my own copy
of Tkinter (built for X11). 

To do this, I passed "LDFLAGS=-rpath,/path/to/lib" to configure so that
Python could find my specific lib files, but I also had to edit Python's
setup.py so that detect_tkinter() would not do anything special for Darwin:

$ diff setup.py original_setup.py 
1199c1199
<         if 0 and (platform == 'darwin' and
---
>         if (platform == 'darwin' and


I did this based on a post by Ronald Oussoren to the Python-SIG Mac
mailing list [http://article.gmane.org/gmane.comp.python.apple/14008].
He also suggested that I file a bug report, asking for an argument to be
added to python's configure script to avoid having to edit setup.py.

Thanks

----------
components: Build, Macintosh, Tkinter
messages: 58413
nosy: ceball
severity: minor
status: open
title: Mac OS X: building with X11 Tkinter
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1584>
__________________________________

From report at bugs.python.org  Tue Dec 11 09:09:36 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Dec 2007 08:09:36 -0000
Subject: [New-bugs-announce] [issue1585] IDLE uses non-existent xrange()
	function (Py30a2)
Message-ID: <1197360576.33.0.156315897213.issue1585@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

When I start IDLE I get this:

Python 3.0a2 (r30a2:59382, Dec 10 2007, 14:21:37) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "copyright", "credits" or "license()" for more information.

    ****************************************************************
    Personal firewall software may warn about the connection IDLE
    makes to its subprocess using this computer's internal loopback
    interface.  This connection is not visible on any external
    interface and no data is sent to or received from the Internet.
    ****************************************************************
    
IDLE 3.0a1      
>>>

That's fine (if slightly confusing regarding the version numbers), but
if I click Options->Configure I get this error output:

: Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/mark/opt/python30a2/lib/python3.0/lib-tk/Tkinter.py", line
1402, 
in __call__
    return self.func(*args)
  File
"/home/mark/opt/python30a2/lib/python3.0/idlelib/EditorWindow.py", line 
385, in config_dialog
    configDialog.ConfigDialog(self.top,'Settings')
  File
"/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
50, in __init__
    self.CreateWidgets()
  File
"/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
69, in CreateWidgets
    page_names=['Fonts/Tabs','Highlighting','Keys','General'])
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
398, in __init__
    self.add_page(name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
413, in add_page
    self._tab_set.add_tab(page_name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
76, in add_tab
    self._arrange_tabs()
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
163, in _arrange_tabs
    for row_index in xrange(n_rows):
NameError: global name 'xrange' is not defined

I tried changing xrange to range, but that doesn't work:

: Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/mark/opt/python30a2/lib/python3.0/lib-tk/Tkinter.py", line
1402, 
in __call__
    return self.func(*args)
  File
"/home/mark/opt/python30a2/lib/python3.0/idlelib/EditorWindow.py", line 
385, in config_dialog
    configDialog.ConfigDialog(self.top,'Settings')
  File
"/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
50, in __init__
    self.CreateWidgets()
  File
"/home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py", line 
69, in CreateWidgets
    page_names=['Fonts/Tabs','Highlighting','Keys','General'])
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
398, in __init__
    self.add_page(name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
413, in add_page
    self._tab_set.add_tab(page_name)
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
76, in add_tab
    self._arrange_tabs()
  File "/home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py",
line 
148, in _arrange_tabs
    for tab_name in self._tabs.keys():
RuntimeError: dictionary changed size during iteration

----------
components: IDLE
messages: 58417
nosy: mark
severity: normal
status: open
title: IDLE uses non-existent xrange() function (Py30a2)
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1585>
__________________________________

From report at bugs.python.org  Tue Dec 11 11:31:46 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Dec 2007 10:31:46 -0000
Subject: [New-bugs-announce] [issue1586] IDLE no longer shows colour syntax
	highlighting in the Shell (Py30a2)
Message-ID: <1197369106.9.0.963432002418.issue1586@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

When I do: 
    import sys; dir(sys)
everything is shown in plain black & white, but in the IDLE that came
with Py30a1 color syntax highlighting is used.

----------
components: IDLE
messages: 58423
nosy: mark
severity: minor
status: open
title: IDLE no longer shows colour syntax highlighting in the Shell (Py30a2)
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1586>
__________________________________

From report at bugs.python.org  Tue Dec 11 13:40:19 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Dec 2007 12:40:19 -0000
Subject: [New-bugs-announce] [issue1587] instancemethod wrapper for
	PyCFunctions
Message-ID: <1197376819.43.0.564314385803.issue1587@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch implements the instancemethod wrapper as discussed on the py3k
mailing list. The patch is roughly based on Marcin Kowalczyk patch but
it contains more fancy slots like repr, call etc. The rest is mostly
based on PyMethod_Type.

----------
components: Interpreter Core
files: py3k_instancemethod.patch
keywords: patch, py3k
messages: 58425
nosy: tiran
priority: normal
severity: normal
status: open
title: instancemethod wrapper for PyCFunctions
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8923/py3k_instancemethod.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1587>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_instancemethod.patch
Type: text/x-diff
Size: 9127 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071211/8a391995/attachment.patch 

From report at bugs.python.org  Tue Dec 11 14:30:51 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Dec 2007 13:30:51 -0000
Subject: [New-bugs-announce] [issue1588] str.format() wrongly formats
	complex() numbers (Py30a2)
Message-ID: <1197379851.58.0.0476028374566.issue1588@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

>>> x = complex(1, 2/3)
>>> "{0} {0:.5}".format(x)
'(1+0.666666666667j) (1+0.'

The complex number is being formatted as if it were a string and simply
truncated to 5 characters. I would expect each part of the complex
number to be formatted according to the format specifier, i.e., in the
case of :.5 to both have 5 digits after the decimal point.

----------
components: Interpreter Core
messages: 58428
nosy: mark
severity: normal
status: open
title: str.format() wrongly formats complex() numbers (Py30a2)
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1588>
__________________________________

From report at bugs.python.org  Tue Dec 11 16:41:03 2007
From: report at bugs.python.org (Andreas Hasenack)
Date: Tue, 11 Dec 2007 15:41:03 -0000
Subject: [New-bugs-announce] [issue1589] New SSL module doesn't seem to
	verify hostname against commonName in certificate
Message-ID: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>


New submission from Andreas Hasenack:

(I hope I used the correct component for this report)

http://pypi.python.org/pypi/ssl/

I used the client example shown at
http://docs.python.org/dev/library/ssl.html#client-side-operation to
connect to a bank site called www.realsecureweb.com.br at
200.208.16.101. Its certificate signed by verisign. My OpenSSL has this
CA at /etc/pki/tls/rootcerts/verisign-inc-class-3-public-primary.pem.
The verification works.

If I make up a hostname called something else, like "wwws", and place it
in /etc/hosts pointing to that IP address, the SSL connection should not
be established because that name doesn't match the common name field in
the server certificate. But the SSL module happily connects to it
(excerpt below):

cert = verisign-inc-class-3-public-primary.pem
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s,
           ca_certs="/etc/pki/tls/rootcerts/%s" % cert,
           cert_reqs=ssl.CERT_REQUIRED)
ssl_sock.connect(('wwws', 443))
print repr(ssl_sock.getpeername())

output:
('200.208.16.101', 443)
('RC4-MD5', 'TLSv1/SSLv3', 128)
{'notAfter': 'Sep 10 23:59:59 2008 GMT',
 'subject': ((('countryName', u'BR'),),
             (('stateOrProvinceName', u'Sao Paulo'),),
             (('localityName', u'Sao Paulo'),),
             (('organizationName', u'Banco ABN AMRO Real SA'),),
             (('organizationalUnitName', u'TI Internet PF e PJ'),),
             (('commonName', u'www.realsecureweb.com.br'),))}

If I now open, say, a firefox window and point it to "https://wwws", it
gives me the expected warning that the hostname doesn't match the
certificate.

I'll attach the verisign CA certificate to make it easier to reproduce
the error.

----------
components: Library (Lib)
files: verisign-inc-class-3-public-primary.pem
messages: 58434
nosy: ahasenack
severity: normal
status: open
title: New SSL module doesn't seem to verify hostname against commonName in certificate
type: security
versions: Python 2.6
Added file: http://bugs.python.org/file8924/verisign-inc-class-3-public-primary.pem

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: verisign-inc-class-3-public-primary.pem
Type: application/x-x509-ca-cert
Size: 2585 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071211/4b01e616/attachment.crt 

From report at bugs.python.org  Tue Dec 11 16:48:35 2007
From: report at bugs.python.org (David Ripton)
Date: Tue, 11 Dec 2007 15:48:35 -0000
Subject: [New-bugs-announce] [issue1590] "make altinstall" installs pydoc,
	idle, smtpd.py
Message-ID: <1197388115.32.0.880215268876.issue1590@psf.upfronthosting.co.za>


New submission from David Ripton:

Python 3.0a2, Gentoo Linux, x86

"make altinstall" installs idle, pydoc, and smtpd.py

This can partially break the previous Python install, which is counter
to the idea of altinstall being safe to use in parallel with an existing
install of a different version of Python.

IMO altinstall should install no files that lack a version number
somewhere in their path.  I suggest having altinstall simply not install
pydoc, idle, and smtpd.py.

----------
components: Build
messages: 58437
nosy: dripton
severity: minor
status: open
title: "make altinstall" installs pydoc, idle, smtpd.py
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1590>
__________________________________

From report at bugs.python.org  Tue Dec 11 18:12:04 2007
From: report at bugs.python.org (Mark Tomczak)
Date: Tue, 11 Dec 2007 17:12:04 -0000
Subject: [New-bugs-announce] [issue1591] popen2.Popen3 class (Unix)
	documentation misleading / confusing
Message-ID: <1197393124.23.0.965302988913.issue1591@psf.upfronthosting.co.za>


New submission from Mark Tomczak:

The help documentation for the popen2.Popen3 class includes the
following information:

    class Popen3
     |  Class representing a child process.  Normally instances are created
     |  by the factory functions popen2() and popen3().

This information is misleading because the function popen2.popen3
actually returns a tuple of file objects (child_stdout, child_stdin,
child_stderr), not an instance of class Popen3. Additionally, some of
the properties of class Popen3 are monkey-patched into the instance when
it is created and so do not appear in a dir(popen2.Popen3) call on the
class itself. This means that some automatic documentation generators
seem to fail to list these properties of the runtime Popen3 instance, as
they are not apparent in the class definition.

I suggest adding a note in the documentation of popen2.Popen3 to refer
users to the manual page http://docs.python.org/lib/popen3-objects.html.
An example of usage that takes into account the monkey-patched
properties would also be helpful.

----------
components: Documentation
messages: 58440
nosy: mtomczak
severity: minor
status: open
title: popen2.Popen3 class (Unix) documentation misleading / confusing
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1591>
__________________________________

From report at bugs.python.org  Tue Dec 11 19:38:16 2007
From: report at bugs.python.org (Erno Kuusela)
Date: Tue, 11 Dec 2007 18:38:16 -0000
Subject: [New-bugs-announce] [issue1592] operations on closed shelves fail
	cryptically
Message-ID: <1197398296.88.0.878837711853.issue1592@psf.upfronthosting.co.za>


New submission from Erno Kuusela:

shelve objects set self.dict = 0 in their close() method. this
results in errors such as TypeError: unsubscriptable object and
AttributeError: 'int' object has no attribute 'has_key'.
This is fairly baffling for the user.

"self.dict = 0" in close() is present in current svn trunk too.

----------
components: Library (Lib)
messages: 58453
nosy: erno
severity: normal
status: open
title: operations on closed shelves fail cryptically
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592>
__________________________________

From report at bugs.python.org  Tue Dec 11 20:23:56 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Tue, 11 Dec 2007 19:23:56 -0000
Subject: [New-bugs-announce] [issue1593] spacing of the builtin_format
	function is inconsistent
Message-ID: <1197401036.82.0.538665971597.issue1593@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

URL: http://svn.python.org/projects/python/branches/py3k
Revision: 59467

The spacing of the builtin_format function did not appear to be
consistent with the rest of the .c file.

See attached patch

----------
components: Interpreter Core
files: bltinmodule.patch
messages: 58459
nosy: JosephArmbruster
severity: normal
status: open
title: spacing of the builtin_format function is inconsistent
versions: Python 3.0
Added file: http://bugs.python.org/file8927/bltinmodule.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1593>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bltinmodule.patch
Type: text/x-diff
Size: 3673 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071211/8852c8e7/attachment.patch 

From report at bugs.python.org  Tue Dec 11 21:20:52 2007
From: report at bugs.python.org (Just van Rossum)
Date: Tue, 11 Dec 2007 20:20:52 -0000
Subject: [New-bugs-announce] [issue1594] MacOS.GetCreatorAndType() and
	SetCreatorAndType() broken on intel
Message-ID: <1197404452.81.0.608484843399.issue1594@psf.upfronthosting.co.za>


New submission from Just van Rossum:

On intel, MacOS.GetCreatorAndType() returns the creator and type code with 
the wrong endianness, eg. as 'DCBA' instead of 'ABCD'.

----------
components: Macintosh
messages: 58464
nosy: jvr
priority: normal
severity: normal
status: open
title: MacOS.GetCreatorAndType() and SetCreatorAndType() broken on intel
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1594>
__________________________________

From report at bugs.python.org  Tue Dec 11 22:40:49 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Dec 2007 21:40:49 -0000
Subject: [New-bugs-announce] [issue1595] Probable extra semicolon in
	Py_LeaveRecursiveCall macro
Message-ID: <1197409249.11.0.710274454226.issue1595@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

In file ceval.h, the macro Py_LeaveRecursiveCall is defined like this:

#define Py_LeaveRecursiveCall()				\
    do{ if((--PyThreadState_GET()->recursion_depth) <   \
	   _Py_CheckRecursionLimit - 50);               \
	  PyThreadState_GET()->overflowed = 0;          \
    } while(0)


The semicolon on the third line seems very suspicious to me: the if()
statement has no side effect, and "overflowed" is always reset to zero.

I don't really understand the consequences, though. The variable seems
to be used as an additional protection against C code that does not
correctly unwind when the recursion limit is hit.

----------
assignee: loewis
components: Interpreter Core
keywords: py3k
messages: 58468
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: Probable extra semicolon in Py_LeaveRecursiveCall macro
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1595>
__________________________________

From report at bugs.python.org  Tue Dec 11 23:02:26 2007
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Dec 2007 22:02:26 -0000
Subject: [New-bugs-announce] [issue1596] Broken pipes should be handled
	better in 2.x
Message-ID: <1197410546.31.0.23440598734.issue1596@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

I think Python 2.x should mimic, or improve on, the behavior of Py3k for
handling broken pipes. That is:
  1. Don't print the message "close failed: [Errno 32] Broken pipe",
from filemodule.c; since this is impossible to override from Python.
  2. Check sys.stdout if it's closed before calling the print routine.
Raise an IOError if so.

Finally, here's some examples to illustrate what I am saying:

alex:~% python -c "print" | head -n0
close failed: [Errno 32] Broken pipe

alex:~% python -c "while 1: print" | head -n0
[The loop continues running, even if the output stream is closed]
^C
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt
close failed: [Errno 32] Broken pipe

alex:~% py3k -c "print()" | head -n0
alex:~% py3k -c "while 1: print()" | head -n0
Traceback (most recent call last):
 ...
IOError: [Errno 32] Broken pipe

----------
components: Interpreter Core
messages: 58469
nosy: alexandre.vassalotti
severity: normal
status: open
title: Broken pipes should be handled better in 2.x
type: rfe
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596>
__________________________________

From report at bugs.python.org  Wed Dec 12 00:41:07 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Dec 2007 23:41:07 -0000
Subject: [New-bugs-announce] [issue1597] running test_ctypes 25 times in a
	row causes it to fail
Message-ID: <1197416467.86.0.651352807459.issue1597@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

In debug mode, on my Ubuntu Linux box, this fails on the last iteration:

$ ./python Lib/test/regrtest.py -R:20 test_ctypes
test_ctypes
beginning 25 repetitions
1234567890123456789012345
........................test test_ctypes failed -- Traceback (most
recent call last):
  File
"/usr/local/google/home/guido/python/py3kd/Lib/ctypes/test/test_values.py",
line 18, in test_an_integer
    self.failUnlessEqual(x*2, ctdll.get_an_integer())
AssertionError: 2818572288 != -1476395008

1 test failed:
    test_ctypes
[104230 refs]
$ 

Also, when using -R:19, I get some random leaks reported of 33 or -33
references leaked.  Does this test use threads?  It seems to have a race
condition.

----------
assignee: theller
messages: 58476
nosy: gvanrossum, theller
priority: normal
severity: normal
status: open
title: running test_ctypes 25 times in a row causes it to fail
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597>
__________________________________

From report at bugs.python.org  Wed Dec 12 03:40:57 2007
From: report at bugs.python.org (Scott Moser)
Date: Wed, 12 Dec 2007 02:40:57 -0000
Subject: [New-bugs-announce] [issue1598] unexpected response in imaplib
Message-ID: <1197427257.83.0.419655228027.issue1598@psf.upfronthosting.co.za>


New submission from Scott Moser:

I'm running into a problem with imaplib where it is unable to download a
message.  The example code at
http://www.python.org/doc/current/lib/imap4-example.html easily
demonstrates the problem.  

#!/usr/bin/python
import getpass, imaplib

M = imaplib.IMAP4("my.imap.host.tld")
M.login(getpass.getuser(), getpass.getpass())
M.debug = 5
M.select("msg-test")
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()

The majority of the messages transfer correctly, but some do not.  I've
put 3 messages in the 'msg-test' folder, and one of them causes the
error below.  

Traceback (most recent call last):
  File "test.py", line 9, in <module>
    typ, data = M.fetch(num, '(RFC822)')
  File "/usr/lib/python2.5/imaplib.py", line 437, in fetch
    typ, dat = self._simple_command(name, message_set, message_parts)
  File "/usr/lib/python2.5/imaplib.py", line 1055, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.5/imaplib.py", line 887, in _command_complete
    raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: FETCH => unexpected response: ')'

imaplib.py has a comment in _get_tagged_response:
   # Some have reported "unexpected response" exceptions.
   # Note that ignoring them here causes loops.
   # Instead, send me details of the unexpected response and
   # I'll update the code in `_get_response()'.

I can not provide access to the imap host, but I can help debug wherever
possible. 

The most recent log messages are in the file attachment.

----------
components: Library (Lib)
files: imaplib-debug.txt
messages: 58482
nosy: smoser
severity: normal
status: open
title: unexpected response in imaplib
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8929/imaplib-debug.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1598>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imaplib-debug.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071212/08190f22/attachment.txt 

From report at bugs.python.org  Wed Dec 12 05:30:42 2007
From: report at bugs.python.org (Pooja)
Date: Wed, 12 Dec 2007 04:30:42 -0000
Subject: [New-bugs-announce] [issue1599] IDLE hangs if os.spwanv command is
	given
Message-ID: <1197433842.53.0.33995748956.issue1599@psf.upfronthosting.co.za>


Changes by Pooja:


----------
components: IDLE
nosy: Pooja
severity: normal
status: open
title: IDLE hangs if os.spwanv command is given
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599>
__________________________________

From report at bugs.python.org  Wed Dec 12 10:04:03 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 12 Dec 2007 09:04:03 -0000
Subject: [New-bugs-announce] [issue1600] str.format() produces different
	output on different platforms (Py30a2)
Message-ID: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

I don't know if this is a bug, but it is certainly a difference in
behavior between platforms:

Python 3.0a2 on linux2:
>>> "{0:.3e}".format(123.45678901)
'1.235e+02'

Python 3.0a2 on win32:
>>> "{0:.3e}".format(123.45678901)
'1.235e+002'

It seems to me that str.format() should produce consistent results
across platforms, but I don't think the PEP says anything either way.

----------
components: Interpreter Core
messages: 58485
nosy: mark
severity: normal
status: open
title: str.format() produces different output on different platforms (Py30a2)
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Wed Dec 12 10:09:59 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 12 Dec 2007 09:09:59 -0000
Subject: [New-bugs-announce] [issue1601] IDLE not working correctly on
	Windows (Py30a2/IDLE30a1)
Message-ID: <1197450599.05.0.953423788601.issue1601@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

(1) IDLE starts up on Windows OK, but if I press Alt+F the file menu
comes up giant sized (i.e., each menu entry is almost as tall as the
screen).
(2) If I open a file using Ctrl+O, the Open dialog pops up fine, but
when I select a file and click Open, IDLE crashes.

Oh, and (no version of) IDLE respects the cursor blink setting on Windows.

----------
components: IDLE
messages: 58486
nosy: mark
severity: normal
status: open
title: IDLE not working correctly on Windows (Py30a2/IDLE30a1)
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1601>
__________________________________

From report at bugs.python.org  Wed Dec 12 10:56:30 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 12 Dec 2007 09:56:30 -0000
Subject: [New-bugs-announce] [issue1602] windows console doesn't print utf8
	(Py30a2)
Message-ID: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

I am not sure if this is a Python bug or simply a limitation of cmd.exe.

I am using Windows XP Home.
I run cmd.exe with the /u option and I have set my console font to
"Lucida Console" (the only TrueType font offered), and I run chcp 65001
to set the utf8 code page.
When I run the following program:

for x in range(32, 2000):
    print("{0:5X} {0:c}".format(x))

one blank line is output.

But if I do chcp 1252 the program prints up to 7F before hitting a
unicode encoding error.

This is different behaviour from Python 2.5.1 which (with a suitably
modified print line) after chcp 65001 prints up to 7F and then fails
with "IOError: [Errno 0] Error".

----------
components: Unicode, Windows
messages: 58487
nosy: mark
severity: normal
status: open
title: windows console doesn't print utf8 (Py30a2)
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
__________________________________

From report at bugs.python.org  Wed Dec 12 11:04:46 2007
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Wed, 12 Dec 2007 10:04:46 -0000
Subject: [New-bugs-announce] [issue1603] Wanted behaviour ?
Message-ID: <1197453886.28.0.882582891366.issue1603@psf.upfronthosting.co.za>


New submission from Stefan Sonnenberg-Carstens:

>>> a = {}
>>> a['a'] = [1,2,3,4,5]
>>> a['b'] = [1,2,3,4,5]
>>> a['c'] = [1,2,3,4,5]
>>> for k in a.keys():
...     print a[k]
...     for t in a[k]:
...             del a[k][a[k].index(t)]
...             print a[k]
...
[1, 2, 3, 4, 5]
[2, 3, 4, 5]
[2, 4, 5]
[2, 4]
[1, 2, 3, 4, 5]
[2, 3, 4, 5]
[2, 4, 5]
[2, 4]
[1, 2, 3, 4, 5]
[2, 3, 4, 5]
[2, 4, 5]
[2, 4]

Does this make sense ?

----------
messages: 58488
nosy: pythonmeister
severity: normal
status: open
title: Wanted behaviour ?
type: behavior
versions: Python 2.3

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1603>
__________________________________

From report at bugs.python.org  Wed Dec 12 18:20:43 2007
From: report at bugs.python.org (Neil Cerutti)
Date: Wed, 12 Dec 2007 17:20:43 -0000
Subject: [New-bugs-announce] [issue1604] collections.deque.__init__ doesn't
	initialize
Message-ID: <1197480043.96.0.892040879032.issue1604@psf.upfronthosting.co.za>


New submission from Neil Cerutti:

Passing an interable to the __init__ method of an existing deque 
appends those elements, rather than reinitializing the deque with the 
items. This is contrary to how list.__init__ works.

test_deque.py verifies the (possibly) incorrect behavior.

----------
components: Library (Lib)
messages: 58501
nosy: Horpner, rhettinger
severity: normal
status: open
title: collections.deque.__init__ doesn't initialize
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1604>
__________________________________

From report at bugs.python.org  Thu Dec 13 02:40:11 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 13 Dec 2007 01:40:11 -0000
Subject: [New-bugs-announce] [issue1605] Semi autogenerated _types module
Message-ID: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A while ago I've experimented with the pyvm module and a semi
auto-generated types list. The patch adds a script that reads
Include/*.h and adds all available PyTypeObjects to Modules/_typesmodule.c.

The patch or script may be useful in the future.

----------
components: Interpreter Core
files: py3k_autogen_types.patch
keywords: patch, py3k
messages: 58511
nosy: tiran
priority: low
severity: normal
status: open
title: Semi autogenerated _types module
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8934/py3k_autogen_types.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1605>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_autogen_types.patch
Type: text/x-diff
Size: 6928 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071213/98ec4853/attachment.patch 

From report at bugs.python.org  Thu Dec 13 03:04:38 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 13 Dec 2007 02:04:38 -0000
Subject: [New-bugs-announce] [issue1606] Doc: subprocess wait() may lead to
	dead lock
Message-ID: <1197511478.48.0.254025525321.issue1606@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The subprocess docs need a warning that code like

p = subprocess.Popen(..., stdout=STDOUT)
p.wait()
p.stdout.read()

can block indefinitely if the program fills the stdout buffer. It needs
an example how to do it right but I don't know the best way to solve the
problem.

----------
components: Documentation
messages: 58514
nosy: tiran
priority: normal
severity: normal
status: open
title: Doc: subprocess wait() may lead to dead lock
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606>
__________________________________

From report at bugs.python.org  Thu Dec 13 08:35:04 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 13 Dec 2007 07:35:04 -0000
Subject: [New-bugs-announce] [issue1607] Patch for TCL 8.5 support
Message-ID: <1197531304.47.0.926710710128.issue1607@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I've tested Tcl 8.5b3, Tk 8.5b3 and Tix 8.4.2 on Windows. IDLE
complained at multiple places that it could not add a Tcl_Obj to a
string (index + "...") or convert it to a float int(float(index)).
Therefor I added an __add__ and __float__ number slot to the C code. I
also had to add two str() calls.

----------
assignee: kbk
components: IDLE
files: py3k_tcltk85.patch
keywords: patch, py3k
messages: 58523
nosy: kbk, tiran
priority: normal
severity: normal
status: open
title: Patch for TCL 8.5 support
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8935/py3k_tcltk85.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1607>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_tcltk85.patch
Type: text/x-diff
Size: 7057 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071213/604806d2/attachment.patch 

From report at bugs.python.org  Thu Dec 13 11:09:57 2007
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 13 Dec 2007 10:09:57 -0000
Subject: [New-bugs-announce] [issue1608] Regression tests crashes with gcc
	4.3
Message-ID: <1197540596.99.0.804396266045.issue1608@psf.upfronthosting.co.za>


New submission from Ismail Donmez:

Checkout Python 2.5 from release25-maint branch, revision 59479

Compiled with gcc 4.3.0 20071212 , make test crashes with the following
output

[... snip ...]
test_socket_ssl
test_socket_ssl skipped -- Use of the `network' resource not enabled
test_socketserver
test_socketserver skipped -- Use of the `network' resource not enabled
test_softspace
test_sort
test_sqlite
test_startfile
test_startfile skipped -- cannot import name startfile
test_str
make: *** [test] Segmentation fault

----------
components: Tests
messages: 58525
nosy: cartman
severity: normal
status: open
title: Regression tests crashes with gcc 4.3
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1608>
__________________________________

From report at bugs.python.org  Thu Dec 13 11:15:19 2007
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 13 Dec 2007 10:15:19 -0000
Subject: [New-bugs-announce] [issue1609] test_re.py fails
Message-ID: <1197540919.17.0.492030457603.issue1609@psf.upfronthosting.co.za>


New submission from Ismail Donmez:

Using python 2.5 revision 59479 from release25-maint branch, 

[~/python-2.5]> LD_LIBRARY_PATH=/home/cartman/python-2.5: ./python
./Lib/test/test_re.py
test_anyall (__main__.ReTests) ... ok
test_basic_re_sub (__main__.ReTests) ... ok
test_bigcharset (__main__.ReTests) ... ok
test_bug_113254 (__main__.ReTests) ... ok
test_bug_1140 (__main__.ReTests) ... ok
test_bug_114660 (__main__.ReTests) ... ok
test_bug_117612 (__main__.ReTests) ... ok
test_bug_418626 (__main__.ReTests) ... ok
test_bug_448951 (__main__.ReTests) ... ok
test_bug_449000 (__main__.ReTests) ... ok
test_bug_449964 (__main__.ReTests) ... ok
test_bug_462270 (__main__.ReTests) ... ok
test_bug_527371 (__main__.ReTests) ... ok
test_bug_545855 (__main__.ReTests) ... ok
test_bug_581080 (__main__.ReTests) ... ok
test_bug_612074 (__main__.ReTests) ... ok
test_bug_725106 (__main__.ReTests) ... ok
test_bug_725149 (__main__.ReTests) ... ok
test_bug_764548 (__main__.ReTests) ... ok
test_bug_817234 (__main__.ReTests) ... ok
test_bug_926075 (__main__.ReTests) ... ok
test_bug_931848 (__main__.ReTests) ... ok
test_category (__main__.ReTests) ... ok
test_constants (__main__.ReTests) ... ok
test_empty_array (__main__.ReTests) ... ok
test_expand (__main__.ReTests) ... ok
test_finditer (__main__.ReTests) ... ok
test_flags (__main__.ReTests) ... ok
test_getattr (__main__.ReTests) ... ok
test_getlower (__main__.ReTests) ... ok
test_groupdict (__main__.ReTests) ... ok
test_ignore_case (__main__.ReTests) ... ok
test_non_consuming (__main__.ReTests) ... ok
test_not_literal (__main__.ReTests) ... ok
test_pickling (__main__.ReTests) ... ok
test_qualified_re_split (__main__.ReTests) ... ok
test_qualified_re_sub (__main__.ReTests) ... ok
test_re_escape (__main__.ReTests) ... ok
test_re_findall (__main__.ReTests) ... ok
test_re_groupref (__main__.ReTests) ... ok
test_re_groupref_exists (__main__.ReTests) ... ok
test_re_match (__main__.ReTests) ... ok
test_re_split (__main__.ReTests) ... ok
test_re_subn (__main__.ReTests) ... ok
test_repeat_minmax (__main__.ReTests) ... ok
test_scanner (__main__.ReTests) ... ok
test_search_coverage (__main__.ReTests) ... ok
test_search_star_plus (__main__.ReTests) ... ok
test_special_escapes (__main__.ReTests) ... ok
test_sre_character_class_literals (__main__.ReTests) ... ok
test_sre_character_literals (__main__.ReTests) ... ok
test_stack_overflow (__main__.ReTests) ... ok
test_sub_template_numeric_escape (__main__.ReTests) ... ok
test_symbolic_refs (__main__.ReTests) ... ok
test_weakref (__main__.ReTests) ... ok

----------------------------------------------------------------------
Ran 55 tests in 0.194s

OK
Running re_tests test suite
=== Failed incorrectly ('(?u)\\b.\\b', u'\xc4', 0, 'found', u'\xc4')
=== Failed incorrectly ('(?u)\\w', u'\xc4', 0, 'found', u'\xc4')

----------
components: Tests
messages: 58527
nosy: cartman
severity: normal
status: open
title: test_re.py fails
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1609>
__________________________________

From report at bugs.python.org  Thu Dec 13 11:17:13 2007
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 13 Dec 2007 10:17:13 -0000
Subject: [New-bugs-announce] [issue1610] test_socket.py fails
Message-ID: <1197541033.39.0.809033429265.issue1610@psf.upfronthosting.co.za>


New submission from Ismail Donmez:

Checkout Python 2.5 from release25-maint branch, revision 59479,

[~/python-2.5]> LD_LIBRARY_PATH=/home/cartman/python-2.5: ./python
./Lib/test/test_socket.py
testCrucialConstants (__main__.GeneralModuleTests) ... ok
testDefaultTimeout (__main__.GeneralModuleTests) ... ok
testGetServBy (__main__.GeneralModuleTests) ... ERROR
testGetSockOpt (__main__.GeneralModuleTests) ... ok
testHostnameRes (__main__.GeneralModuleTests) ... ok
testIPv4toString (__main__.GeneralModuleTests) ... ok
testIPv6toString (__main__.GeneralModuleTests) ... ok
testInterpreterCrash (__main__.GeneralModuleTests) ... ok
testNewAttributes (__main__.GeneralModuleTests) ... ok
testNtoH (__main__.GeneralModuleTests) ... ok
testRefCountGetNameInfo (__main__.GeneralModuleTests) ... ok
testSendAfterClose (__main__.GeneralModuleTests) ... ok
testSetSockOpt (__main__.GeneralModuleTests) ... ok
testSockName (__main__.GeneralModuleTests) ... ok
testSocketError (__main__.GeneralModuleTests) ... ok
testStringToIPv4 (__main__.GeneralModuleTests) ... ok
testStringToIPv6 (__main__.GeneralModuleTests) ... ok
test_weakref (__main__.GeneralModuleTests) ... ok
testFromFd (__main__.BasicTCPTest) ... ok
testOverFlowRecv (__main__.BasicTCPTest) ... ok
testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok
testRecv (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicTCPTest) ... ok
testSendAll (__main__.BasicTCPTest) ... ok
testShutdown (__main__.BasicTCPTest) ... ok
testClose (__main__.TCPCloserTest) ... ok
testInterruptedTimeout (__main__.TCPTimeoutTest) ... ok
testTCPTimeout (__main__.TCPTimeoutTest) ... ok
testTimeoutZero (__main__.TCPTimeoutTest) ... ok
testExceptionTree (__main__.TestExceptions) ... ok
testRecvFromInto (__main__.BufferIOTest) ... ok
testRecvInto (__main__.BufferIOTest) ... ok
testRecvFrom (__main__.BasicUDPTest) ... ok
testRecvFromNegative (__main__.BasicUDPTest) ... ok
testSendtoAndRecv (__main__.BasicUDPTest) ... ok
testTimeoutZero (__main__.UDPTimeoutTest) ... ok
testUDPTimeout (__main__.UDPTimeoutTest) ... ok
testAccept (__main__.NonBlockingTCPTests) ... ok
testConnect (__main__.NonBlockingTCPTests) ... ok
testRecv (__main__.NonBlockingTCPTests) ... ok
testSetBlocking (__main__.NonBlockingTCPTests) ... ok
testClosedAttr (__main__.FileObjectClassTestCase) ... ok
testFullRead (__main__.FileObjectClassTestCase) ... ok
testReadline (__main__.FileObjectClassTestCase) ... ok
testSmallRead (__main__.FileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.FileObjectClassTestCase) ... ok
testClosedAttr (__main__.UnbufferedFileObjectClassTestCase) ... ok
testFullRead (__main__.UnbufferedFileObjectClassTestCase) ... ok
testReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok
testSmallRead (__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok
testClosedAttr (__main__.LineBufferedFileObjectClassTestCase) ... ok
testFullRead (__main__.LineBufferedFileObjectClassTestCase) ... ok
testReadline (__main__.LineBufferedFileObjectClassTestCase) ... ok
testSmallRead (__main__.LineBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.LineBufferedFileObjectClassTestCase) ... ok
testClosedAttr (__main__.SmallBufferedFileObjectClassTestCase) ... ok
testFullRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok
testReadline (__main__.SmallBufferedFileObjectClassTestCase) ... ok
testSmallRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok
testClose (__main__.Urllib2FileobjectTest) ... ok
testRecv (__main__.BasicSocketPairTest) ... ok
testSend (__main__.BasicSocketPairTest) ... ok
testLinuxAbstractNamespace (__main__.TestLinuxAbstractNamespace) ... ok
testMaxName (__main__.TestLinuxAbstractNamespace) ... ok
testNameOverflow (__main__.TestLinuxAbstractNamespace) ... ok

======================================================================
ERROR: testGetServBy (__main__.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 344, in testGetServBy
    eq(socket.getservbyport(port2), service)
error: port/proto not found

----------------------------------------------------------------------
Ran 68 tests in 5.558s

FAILED (errors=1)
Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 995, in <module>
    test_main()
  File "./Lib/test/test_socket.py", line 991, in test_main
    test_support.run_unittest(*tests)
  File "/home/cartman/python-2.5/Lib/test/test_support.py", line 441, in
run_unittest
    run_suite(suite, testclass)
  File "/home/cartman/python-2.5/Lib/test/test_support.py", line 426, in
run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 344, in testGetServBy
    eq(socket.getservbyport(port2), service)
error: port/proto not found

----------
components: Tests
messages: 58528
nosy: cartman
severity: normal
status: open
title: test_socket.py fails
type: compile error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1610>
__________________________________

From report at bugs.python.org  Thu Dec 13 15:13:14 2007
From: report at bugs.python.org (Pat LaVarre)
Date: Thu, 13 Dec 2007 14:13:14 -0000
Subject: [New-bugs-announce] [issue1611] doctest.testmod gets noisy if
	called more than once per SystemExit
Message-ID: <1197555194.14.0.664818118617.issue1611@psf.upfronthosting.co.za>


New submission from Pat LaVarre:

SUMMARY:

Calling doctest.testmod more than once before SystemExit spews stderr 
messages such as "*** DocTestRunner.merge: '__main__' in both testers; 
summing outcomes"

STEPS TO REPRODUCE:

$ cat tttestmod.py 
import doctest
doctest.testmod() # 1
doctest.testmod() # 2
doctest.testmod() # 3
$ 

ACTUAL RESULTS:

$ python ./tttestmod.py 
*** DocTestRunner.merge: '__main__' in both testers; summing outcomes.
*** DocTestRunner.merge: '__main__' in both testers; summing outcomes.
$ 

EXPECTED RESULTS:

$ python ./tttestmod.py 
$ 

WORKAROUND:

Filter stdout.write calls from doctest.py to squelch the noise.

REGRESSION/ ISOLATION:

$ python --version
Python 2.5.1
$

Also mentioned 2006-10 in comp.lang.python at DocTestRunner.merge 
verbose,
i.e., http://groups.google.com/group/comp.lang.python/search?
group=comp.lang.python&q=DocTestRunner.merge+verbose

Not yet found in Bugs.python.org at DocTestRunner.

NOTES:

We can reasonably expect newbies to doctest random things
that need to be doctested more than once.

We can't reasonably expect newbies to know to how to filter doctest 
stdout,
for example as below.

#!/usr/bin/env python

r""" ttestmod.py

Filter Doctest stdout a la http://wiki.python.org/moin/doctest
to call doctest.testmod more than once per SystemExit
without producing noise.

>>> import random
>>> import sys
>>>
>>> die = random.randint(1, 6)
>>> print >>sys.stderr, die
>>>
>>> die == 6
True
>>>

"""

import sys

class DocTestOutput:

	def __init__(self, out = sys.stdout):

		self.out = out
		self.write = self.writeOut
		self.quietly = False

	def writeOut(self, bytes):

		head = "*** DocTestRunner.merge: '__main__"
		tail = "' in both testers; summing outcomes."

		if bytes.startswith(head):
			if bytes.endswith(tail):
				self.quietly = True

		if not self.quietly:
			self.out.write(bytes)

		if 0 <= bytes.find('\n'):
			self.quietly = False

if __name__ == '__main__':

	import doctest

	sys.stdout = DocTestOutput()

	doctest.testmod()
	doctest.testmod()

----------
components: Library (Lib)
messages: 58533
nosy: p.lavarre at ieee.org
severity: normal
status: open
title: doctest.testmod gets noisy if called more than once per SystemExit
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1611>
__________________________________

From report at bugs.python.org  Thu Dec 13 16:41:06 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 13 Dec 2007 15:41:06 -0000
Subject: [New-bugs-announce] [issue1612] infinite recursion when using
	collections.Sequence in a recursive function (Py30a2)
Message-ID: <1197560466.82.0.156189455789.issue1612@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

In the attached file there are two tiny functions, flatten1() and
flatten2(). There is only one difference between them:
flatten1() has the line:
    if isinstance(x, list):
and flatten2() has this line instead:
    if isinstance(x, collections.Sequence):

flatten1() works perfectly in Python 2.5.1 and Python 30a2 (just comment
out the flatten2() code).
But flatten2() goes into "infinite" recursion in Python 30a2 when trying
to flatten list "c".

----------
components: Interpreter Core
files: bug.py
messages: 58536
nosy: mark
severity: normal
status: open
title: infinite recursion when using collections.Sequence in a recursive function (Py30a2)
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8939/bug.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.py
Type: text/x-python
Size: 1344 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071213/b45bee93/attachment.py 

From report at bugs.python.org  Thu Dec 13 18:52:31 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 13 Dec 2007 17:52:31 -0000
Subject: [New-bugs-announce] [issue1613] Makefile's VPATH feature is broken
Message-ID: <1197568351.3.0.317308643317.issue1613@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Makefile has a feature called VPATH that is often used for cross
platform compilation or the creation of a different flavor.

Example:

$ cd py3k
$ mkdir debug
$ cd debug
$ ../configure --with-pydebug
$ make
...
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I.
-IInclude -I../Include   -DPy_BUILD_CORE -o Python/mysnprintf.o
../Python/mysnprintf.c
gcc -pthread -g -Wall -Wstrict-prototypes   Parser/acceler.o
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o
Python/mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o
Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
gcc: Parser/tokenizer_pgen.o: No such file or directory
gcc: Parser/printgrammar.o: No such file or directory
gcc: Parser/pgenmain.o: No such file or directory

----------
components: Build
keywords: py3k
messages: 58539
nosy: tiran
priority: normal
severity: normal
status: open
title: Makefile's VPATH feature is broken
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613>
__________________________________

From report at bugs.python.org  Thu Dec 13 19:06:37 2007
From: report at bugs.python.org (Bob Helmbold)
Date: Thu, 13 Dec 2007 18:06:37 -0000
Subject: [New-bugs-announce] [issue1614] bug in string method "title"
Message-ID: <1197569197.0.0.955231241156.issue1614@psf.upfronthosting.co.za>


New submission from Bob Helmbold:

Summary: "title" method of string objects does not 
   handle contractions and possessives correctly.
See the following short program and its results for examples.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
"""
Test of string method 'capitalize'
"""

stringList=["we're",
            "you're",
            "they're",
            "i've",
            "we've",
            "you've",
            "they've",
            "can't",
            "won't",
            "doesn't",
            "haven't",
            "daren't",
            "shouldn't",
            "weren't",
            "wasn't",
            "i'm"
            ]

for item in stringList:
    n=len(item)
    spaces=' '*(12-n)
    itemTitled = item.title()
    isATitle = itemTitled.istitle()
    print "%s -> %s%s is title=%s" %(item, spaces, itemTitled, isATitle)

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Results in:
we're ->        We'Re is title=True
you're ->       You'Re is title=True
they're ->      They'Re is title=True
i've ->         I'Ve is title=True
we've ->        We'Ve is title=True
you've ->       You'Ve is title=True
they've ->      They'Ve is title=True
can't ->        Can'T is title=True
won't ->        Won'T is title=True
doesn't ->      Doesn'T is title=True
haven't ->      Haven'T is title=True
daren't ->      Daren'T is title=True
shouldn't ->    Shouldn'T is title=True
weren't ->      Weren'T is title=True
wasn't ->       Wasn'T is title=True
i'm ->          I'M is title=True

----------
components: Interpreter Core
messages: 58544
nosy: ElGordo
severity: normal
status: open
title: bug in string method "title"
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1614>
__________________________________

From report at bugs.python.org  Thu Dec 13 21:13:37 2007
From: report at bugs.python.org (ganges master)
Date: Thu, 13 Dec 2007 20:13:37 -0000
Subject: [New-bugs-announce] [issue1615] descriptor protocol bug
Message-ID: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>


New submission from ganges master:

it seems the code of PyObject_GenericGetAttr, which invokes the
descriptor protocol, silences any AttributeErrors raised by the
descriptor, for classes that also define __getattr__. it should
propagate up rather than being silently ignored.

the attached example is quite artificial, but it's a simplification of
real world code i had hard time debugging. turned out i misspelled an
attribute name inside the property getter function, which raised an
AttributeError as expected -- but the exception i got was quite
misleading, saying the instance has no attribute named so.

this bug only happens when the class defines a custom __getattr__. see
attached demo file for details.

----------
components: Interpreter Core
files: demo.txt
messages: 58581
nosy: gangesmaster
severity: normal
status: open
title: descriptor protocol bug
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8943/demo.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: demo.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071213/569de793/attachment.txt 

From report at bugs.python.org  Thu Dec 13 21:25:17 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 13 Dec 2007 20:25:17 -0000
Subject: [New-bugs-announce] [issue1616] compiler warnings (gcc 2.96)
Message-ID: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I figured this would be useful:

/home/guido/p25/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning:
function declaration isn't a prototype
/home/guido/p25/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning:
function declaration isn't a prototype
/home/guido/p25/Modules/unicodedata.c: In function `unicodedata_decimal':
/home/guido/p25/Modules/unicodedata.c:110: warning: `rc' might be used
uninitialized in this function
/home/guido/p25/Modules/unicodedata.c: In function `unicodedata_numeric':
/home/guido/p25/Modules/unicodedata.c:197: warning: `rc' might be used
uninitialized in this function
/home/guido/p25/Modules/readline.c: In function `flex_complete':
/home/guido/p25/Modules/readline.c:681: warning: implicit declaration of
function `completion_matches'
/home/guido/p25/Modules/readline.c:681: warning: return makes pointer
from integer without a cast
/home/guido/p25/Modules/cjkcodecs/_codecs_iso2022.c: In function
`iso2022processesc':
/home/guido/p25/Modules/cjkcodecs/_codecs_iso2022.c:307: warning:
`esclen' might be used uninitialized in this function

----------
assignee: gvanrossum
messages: 58582
nosy: gvanrossum
priority: low
severity: normal
status: open
title: compiler warnings (gcc 2.96)
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
__________________________________

From report at bugs.python.org  Thu Dec 13 22:07:48 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 13 Dec 2007 21:07:48 -0000
Subject: [New-bugs-announce] [issue1617] Rare exception in test_urllib2net
Message-ID: <1197580068.32.0.710021018285.issue1617@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

test test_urllib2net failed -- Traceback (most recent call last):
 File "/tmp/python-test/local/lib/python2.6/test/test_urllib2net.py",
line 175, in test_ftp
   self._test_urls(urls, self._extra_handlers())
 File "/tmp/python-test/local/lib/python2.6/test/test_urllib2net.py",
line 244, in _test_urls
   f = urllib2.urlopen(url, req)
 File "/tmp/python-test/local/lib/python2.6/urllib2.py", line 124, in
urlopen
   return _opener.open(url, data, timeout)
 File "/tmp/python-test/local/lib/python2.6/urllib2.py", line 380, in open
   response = self._open(req, data)
 File "/tmp/python-test/local/lib/python2.6/urllib2.py", line 398, in _open
   '_open', req)
 File "/tmp/python-test/local/lib/python2.6/urllib2.py", line 358, in
_call_chain
   result = func(*args)
 File "/tmp/python-test/local/lib/python2.6/urllib2.py", line 1277, in
ftp_open
   fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
 File "/tmp/python-test/local/lib/python2.6/urllib2.py", line 1323, in
connect_ftp
   self.cache[key] = ftpwrapper(user, passwd, host, port, dirs, timeout)
 File "/tmp/python-test/local/lib/python2.6/urllib.py", line 842, in
__init__
   self.init()
 File "/tmp/python-test/local/lib/python2.6/urllib.py", line 848, in init
   self.ftp.connect(self.host, self.port, self.timeout)
 File "/tmp/python-test/local/lib/python2.6/ftplib.py", line 129, in connect
   self.sock = socket.create_connection((self.host, self.port),
self.timeout)
 File "/tmp/python-test/local/lib/python2.6/socket.py", line 462, in
create_connection
   raise error, msg
TypeError: __init__() takes exactly 2 arguments (3 given)

It looks like somehow msg is a 2-tuple here.  What exception could have
been caught?

----------
messages: 58588
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Rare exception in test_urllib2net
type: crash
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1617>
__________________________________

From report at bugs.python.org  Thu Dec 13 22:41:48 2007
From: report at bugs.python.org (Filip Salomonsson)
Date: Thu, 13 Dec 2007 21:41:48 -0000
Subject: [New-bugs-announce] [issue1618] locale.strxfrm can't handle
	non-ascii strings
Message-ID: <1197582108.61.0.124909155583.issue1618@psf.upfronthosting.co.za>


New submission from Filip Salomonsson:

locale.strxfrm currently does not handle non-ascii strings:

$ ./python
Python 3.0a2 (py3k:59482, Dec 13 2007, 21:27:14) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_COLLATE, "en_US.utf8")
'en_US.utf8'
>>> locale.strxfrm("a")
'\x0c\x01\x08\x01\x02'
>>> locale.strxfrm("\N{LATIN SMALL LETTER A WITH DIAERESIS}")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: strxfrm() argument 1 must be string without null bytes, not str

The attached patch tries to fix this:

$ ./python
Python 3.0a2 (py3k:59482M, Dec 13 2007, 21:58:09) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_COLLATE, "en_US.utf8")
'en_US.utf8'
>>> locale.strxfrm("a")
'.\x01\x10\x01\x02'
>>> locale.strxfrm("\N{LATIN SMALL LETTER A WITH DIAERESIS}")
'.\x01\x19\x01\x02'
>>> alist = list("abo???ABO?????")
>>> sorted(alist, cmp=locale.strcoll) == sorted(alist, key=locale.strxfrm)
True


The patch does not include what's needed to define HAVE_WCSXFRM, since I
really don't know how to do that properly (I edited 'configure' and
'pyconfig.h.in' manually to compile it).

----------
files: strxfrm-unicode.diff
messages: 58592
nosy: filips
severity: normal
status: open
title: locale.strxfrm can't handle non-ascii strings
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8946/strxfrm-unicode.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1618>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strxfrm-unicode.diff
Type: text/x-patch
Size: 1589 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071213/a8d10ae2/attachment-0001.bin 

From report at bugs.python.org  Thu Dec 13 23:23:10 2007
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 13 Dec 2007 22:23:10 -0000
Subject: [New-bugs-announce] [issue1619] Test
Message-ID: <1197584590.28.0.311215540879.issue1619@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
nosy: loewis
severity: normal
status: open
title: Test

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1619>
__________________________________

From report at bugs.python.org  Fri Dec 14 01:26:26 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 14 Dec 2007 00:26:26 -0000
Subject: [New-bugs-announce] [issue1620] New @spam.getter property syntax
	modifies the property in place
Message-ID: <1197591986.68.0.971719358978.issue1620@psf.upfronthosting.co.za>


New submission from Christian Heimes:

As reported by Duncan Booth at
http://permalink.gmane.org/gmane.comp.python.general/551183 the new
@spam.getter syntax modifies the property in place but it should create
a new one.

The patch is the first draft of a fix. I've to write unit tests to
verify the patch. It copies the property and as a bonus grabs the
__doc__ string from the getter if the doc string initially came from the
getter as well.

----------
assignee: tiran
components: Interpreter Core
files: py3k_copy_property.patch
keywords: patch, py3k
messages: 58598
nosy: gvanrossum, tiran
priority: high
severity: normal
status: open
title: New @spam.getter property syntax modifies the property in place
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8947/py3k_copy_property.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1620>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_copy_property.patch
Type: text/x-diff
Size: 4591 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071214/68acf5c2/attachment.patch 

From report at bugs.python.org  Fri Dec 14 01:43:47 2007
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 14 Dec 2007 00:43:47 -0000
Subject: [New-bugs-announce] [issue1621] Python should compile with
	-Wstrict-overflow when using gcc
Message-ID: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The resolution to http://bugs.python.org/issue1608 looks like it'll add
a -fwrapv gcc flag when building python.  This works around the issue
nicely on one compiler (gcc) but doesn't fix our fundamentally broken code.

We should fix all dependencies on integer overflow behavior, starting by
making everything compile properly with gcc's -Wstrict-overflow and
-Werror flags.

----------
messages: 58602
nosy: gregory.p.smith
severity: normal
status: open
title: Python should compile with -Wstrict-overflow when using gcc
type: security
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
__________________________________

From report at bugs.python.org  Fri Dec 14 02:31:18 2007
From: report at bugs.python.org (Eric Huss)
Date: Fri, 14 Dec 2007 01:31:18 -0000
Subject: [New-bugs-announce] [issue1622] zipfile hangs on certain zip files
Message-ID: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za>


New submission from Eric Huss:

Creating a ZipFile object with a certain type of zip file can cause it
to go into an infinite loop.  The problem is the new extra field parsing
routine.  It unpacks integers as a signed value, which if they are
sufficiently large (over 32767), then it will loop forever.

There are many places in the zipfile module that incorrectly unpack
values as signed integers, but this is the only place that I can
determine that causes a serious problem.

Attached is a fix.

----------
components: Library (Lib)
files: zipfile.patch
messages: 58606
nosy: ehuss
severity: normal
status: open
title: zipfile hangs on certain zip files
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8948/zipfile.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1622>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zipfile.patch
Type: application/octet-stream
Size: 457 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071214/ff72c7b6/attachment.obj 

From report at bugs.python.org  Fri Dec 14 06:35:04 2007
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 14 Dec 2007 05:35:04 -0000
Subject: [New-bugs-announce] [issue1623] Implement PEP-3141 for Decimal
Message-ID: <1197610504.39.0.97604614618.issue1623@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

I added __round__, __ceil__, __floor__, and __trunc__

----------
components: Library (Lib)
files: decimal_3141.patch
messages: 58614
nosy: jyasskin
severity: normal
status: open
title: Implement PEP-3141 for Decimal
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8951/decimal_3141.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1623>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decimal_3141.patch
Type: application/octet-stream
Size: 4058 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071214/baf14910/attachment.obj 

From report at bugs.python.org  Fri Dec 14 10:09:08 2007
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Dec 2007 09:09:08 -0000
Subject: [New-bugs-announce] [issue1624] Remove output comparison for
	test_pep277
Message-ID: <1197623348.52.0.389578727596.issue1624@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The output from test_pep277.py seems to be completely worthless in terms
of testing.  The attached patch removes the output comparison file from
Lib/test/output and changes test_pep277.py to not output anything.  But
since I don't have a Windows box I can't test this patch to commit it
myself.

----------
components: Tests
files: rm_output-test_pep277.diff
messages: 58618
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Remove output comparison for test_pep277
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8952/rm_output-test_pep277.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1624>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rm_output-test_pep277.diff
Type: application/octet-stream
Size: 1312 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071214/20d443ac/attachment-0001.obj 

From report at bugs.python.org  Fri Dec 14 10:20:30 2007
From: report at bugs.python.org (Thomas Herve)
Date: Fri, 14 Dec 2007 09:20:30 -0000
Subject: [New-bugs-announce] [issue1625] bz2.BZ2File doesn't support
	multiple streams
Message-ID: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>


New submission from Thomas Herve:

The BZ2File class only supports one stream per file. It possible to have
multiple streams concatenated in one file, it the resulting data should
be the concatenation of all the streams. It's what the bunzip2 program
produces, for example. It's also supported by the gzip module.

Once this done, this would add the ability to open a file for appending,
by adding another stream to the file.

I'll probably try to do this, but the fact it's done in C (unlike gzip)
makes it harder, so if someone beats me to it, etc.

----------
components: Library (Lib)
messages: 58619
nosy: therve
severity: normal
status: open
title: bz2.BZ2File doesn't support multiple streams
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
__________________________________

From report at bugs.python.org  Fri Dec 14 13:11:47 2007
From: report at bugs.python.org (Sebastien BRACQUEMONT)
Date: Fri, 14 Dec 2007 12:11:47 -0000
Subject: [New-bugs-announce] [issue1626] threading.Thread objects are not
	reusable after join()
Message-ID: <1197634307.43.0.872596280965.issue1626@psf.upfronthosting.co.za>


New submission from Sebastien BRACQUEMONT:

After a call to join() method on a Threading.thread object,there is no
way to successfully call start() method on it.

Indeed, the __started flag is not reset in the theading.Thread join()
method. 
Since the start() method checks for __started flag , this flag is always  
true after a first start, despite the thread was effectively stopped by
the join() call

Since it's perfectly legal to store a threading.Thread object in a
variable or an object member, i think the join() behaviour is odd
because it prevents instance reusability.

----------
components: Library (Lib)
messages: 58622
nosy: dweeves
severity: normal
status: open
title: threading.Thread objects are not reusable after join()
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626>
__________________________________

From report at bugs.python.org  Fri Dec 14 13:52:01 2007
From: report at bugs.python.org (=?utf-8?q?=C3=81lvaro_Iradier?=)
Date: Fri, 14 Dec 2007 12:52:01 -0000
Subject: [New-bugs-announce] [issue1627] Problem with httplib and
	Content-Length: -1
Message-ID: <1197636721.61.0.0455165758222.issue1627@psf.upfronthosting.co.za>


New submission from ?lvaro Iradier:

When opening an IP Webcam URL with urllib2, the response is a continuous
secuence of Jpeg files from the server, preceded by the following headers:

Server: DM-Web
Content-type:
multipart/x-mixed-replace;boundary=0plm(Pico-Web:Server-Push:Boundary-String)1qaz
Content-length: -1

As you can see, the Content-Type is multipart/x-mixed-replace, and the
Content-Length reported by the server is '-1', which is strange (I guess
it would be better not to report Content-Length)

The problem is trying to read anything from the file-like object
returned by urlopen will block forever. Problem seems to be here, in
httplib.py, class HTTPResponse, method 'begin':

...
        # will the connection close at the end of the response?
        self.will_close = self._check_close()

        # do we have a Content-Length?
        # NOTE: RFC 2616, S4.4, #3 says we ignore this if tr_enc is
"chunked"
        length = self.msg.getheader('content-length')
        if length and not self.chunked:
            try:
                self.length = int(length)
            except ValueError:
                self.length = None
        else:
            self.length = None
...

The length attribute is being set to '-1' which leads to blocking when
reading from the endless stream of data. (See the read method in class
_fileobject, socket.py).

I don't know if this is the right fix, but I would suggest changing:

        length = self.msg.getheader('content-length')
        if length and not self.chunked:

to:

        length = self.msg.getheader('content-length')
        if length >= 0 and not self.chunked:

----------
components: Library (Lib)
messages: 58624
nosy: airadier
severity: major
status: open
title: Problem with httplib and Content-Length: -1
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1627>
__________________________________

From report at bugs.python.org  Fri Dec 14 14:34:41 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Fri, 14 Dec 2007 13:34:41 -0000
Subject: [New-bugs-announce] [issue1628] test_distutils unit test is failing
	rev:59499
Message-ID: <1197639281.85.0.668104376803.issue1628@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

Error detailed below.. I reverted the changes to sysconfig.py from rev
59488 and the error goes away.  I believe the suspect line is:

# head
python_build = os.path.isfile(os.path.join(project_base, "Modules",
                                           "Setup.local"))
# after revert
python_build = os.path.isfile(os.path.join(project_base, "Modules",
                                           "Setup.dist"))



D:\work\py trunk\PCbuild9>rt test_distutils
Deleting .pyc/.pyo files ...
92 .pyc deleted, 0 .pyo deleted

D:\work\py trunk\PCbuild9>python  -E -tt ../lib/test/regrtest.py
test_distutils
test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "D:\work\py trunk\lib\distutils\tests\test_sysconfig.py", line
16, in test_get_config_h_filename
    self.assert_(os.path.isfile(config_h), config_h)
AssertionError: D:\work\py trunk\include\pyconfig.h

1 test failed:
    test_distutils
About to run again without deleting .pyc/.pyo first:
Press any key to continue . . .

----------
components: Distutils
messages: 58626
nosy: JosephArmbruster, tiran
severity: normal
status: open
title: test_distutils unit test is failing rev:59499
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628>
__________________________________

From report at bugs.python.org  Fri Dec 14 20:45:41 2007
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Dec 2007 19:45:41 -0000
Subject: [New-bugs-announce] [issue1629] Py_Size() should be named Py_SIZE()
Message-ID: <1197661541.29.0.0994895685418.issue1629@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

It would be helpful to have the name provide a cue that a macro is being
used.

----------
assignee: loewis
components: Extension Modules
messages: 58634
nosy: loewis, rhettinger
severity: normal
status: open
title: Py_Size() should be named Py_SIZE()
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1629>
__________________________________

From report at bugs.python.org  Sat Dec 15 02:00:02 2007
From: report at bugs.python.org (Blair Zajac)
Date: Sat, 15 Dec 2007 01:00:02 -0000
Subject: [New-bugs-announce] [issue1630] sys.maxint is documented but should
	not be
Message-ID: <1197680402.4.0.730007198263.issue1630@psf.upfronthosting.co.za>


New submission from Blair Zajac:

There is still documentation for sys.maxint even though it no
longer exists in Python 3.0:

$ /tmp/p3.0/bin/python
Python 3.0a2 (r30a2:59382, Dec 13 2007, 11:07:38)
[GCC 3.4.3 20050227 (Red Hat 3.4.3-22.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> [x for x in sys.__doc__.split('\n') if x.find('maxint') != -1]
['maxint -- the largest supported integer (the smallest is -maxint-1)']
>>> sys.maxint
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'maxint'

----------
components: Library (Lib)
messages: 58645
nosy: blair
severity: normal
status: open
title: sys.maxint is documented but should not be
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1630>
__________________________________

From report at bugs.python.org  Sat Dec 15 02:01:33 2007
From: report at bugs.python.org (Nishkar Grover)
Date: Sat, 15 Dec 2007 01:01:33 -0000
Subject: [New-bugs-announce] [issue1631] Send output from subprocess.Popen
	objects to any object with a write() method
Message-ID: <1197680493.69.0.0120420737472.issue1631@psf.upfronthosting.co.za>


New submission from Nishkar Grover:

It would be nice if we could send output from subprocess.Popen objects
to any object with a write() method.

Consider the following example, where I'm using Python 2.4.4 (#1, Jun 28
2007, 15:10:17, GCC 3.4.3 on linux2)...

>>>
>>> fh = open('/tmp/file.txt', 'w')
>>> cmdObj = subprocess.Popen('uname -a', shell=True, stdout=fh)
>>> fh.close()
>>> fh = open('/tmp/file.txt', 'r')
>>> fh.read()
'Linux northstar 2.6.9-42.0.2.IT111843.1.ELsmp #1 SMP Fri May 11
18:50:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux\n'
>>>

That demonstrates that I can successfully send the stdout output from my
subprocess.Popen object to a file handle.

I tried to send that output to a custom object that has a write() method...

>>>
>>> class Foo(object):
...     def write(self, msg):
...         sys.stdout.write('*** %s ***' % msg.rstrip() + os.linesep)
...         sys.stdout.flush()
...     def close(self):
...         pass
...
>>>
>>> foo = Foo()
>>>
>>> cmdObj = subprocess.Popen('uname -a', shell=True, stdout=foo)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/rel/lang/python/2.4.4-4/lib/python2.4/subprocess.py", line 534,
in __init__
    (p2cread, p2cwrite,
  File "/rel/lang/python/2.4.4-4/lib/python2.4/subprocess.py", line 840,
in _get_handles
    c2pwrite = stdout.fileno()
AttributeError: 'Foo' object has no attribute 'fileno'
>>>

so I gave it a fileno() method that returns None...

>>>
>>> class Foo(object):
...     def write(self, msg):
...         sys.stdout.write('*** %s ***' % msg.rstrip() + os.linesep)
...         sys.stdout.flush()
...     def close(self):
...         pass
...     def fileno(self):
...         return None
...
>>>
>>> foo = Foo()
>>>
>>> cmdObj = subprocess.Popen('uname -a', shell=True, stdout=foo)
>>> Linux northstar 2.6.9-42.0.2.IT111843.1.ELsmp #1 SMP Fri May 11
18:50:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
>>>

Notice that the output went straight to the console and bypassed my
'foo' object's write() method.

----------
components: Library (Lib)
messages: 58646
nosy: ngrover
severity: normal
status: open
title: Send output from subprocess.Popen objects to any object with a write() method
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631>
__________________________________

From report at bugs.python.org  Sat Dec 15 04:55:53 2007
From: report at bugs.python.org (Wubbulous)
Date: Sat, 15 Dec 2007 03:55:53 -0000
Subject: [New-bugs-announce] [issue1632] email
Message-ID: <1197690952.95.0.817718487999.issue1632@psf.upfronthosting.co.za>


New submission from Wubbulous:

Python will not load the email module or any of its child modules.

----------
components: Library (Lib)
messages: 58652
nosy: Wubbulous
severity: major
status: open
title: email
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1632>
__________________________________

From report at bugs.python.org  Sat Dec 15 04:58:08 2007
From: report at bugs.python.org (Wubbulous)
Date: Sat, 15 Dec 2007 03:58:08 -0000
Subject: [New-bugs-announce] [issue1633] smtplib
Message-ID: <1197691088.78.0.165978676778.issue1633@psf.upfronthosting.co.za>


New submission from Wubbulous:

SMTP module returns "no module named SMTP"

----------
components: Library (Lib)
messages: 58653
nosy: Wubbulous
severity: normal
status: open
title: smtplib
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633>
__________________________________

From report at bugs.python.org  Sat Dec 15 06:49:29 2007
From: report at bugs.python.org (Nathan Turner)
Date: Sat, 15 Dec 2007 05:49:29 -0000
Subject: [New-bugs-announce] [issue1634] with Statement Error generated
	following Tutorial
Message-ID: <1197697769.28.0.298338342184.issue1634@psf.upfronthosting.co.za>


New submission from Nathan Turner:

In Python Tutorial -- Section 8.7 "Predefined Clean-up Action"
When following the "with open..." commands explicitly Python 2.5 will
generate a Syntax Error;
"There's an error in you program: invalid syntax"

It would be nice if a foot note existed that took you to Python
Reference Manual -- section 7.5 "The with statement"
In that section it explains that in Python 2.5 you need to use

from __future__ import with_statement


For new users this might frustrate.

----------
components: Documentation
messages: 58659
nosy: astral451
severity: normal
status: open
title: with Statement Error generated following Tutorial
type: compile error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1634>
__________________________________

From report at bugs.python.org  Sat Dec 15 11:23:24 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 15 Dec 2007 10:23:24 -0000
Subject: [New-bugs-announce] [issue1635] Float patch for inf and nan on
	Windows (and other platforms)
Message-ID: <1197714204.6.0.358180315709.issue1635@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch unifies the creation and representation of "inf", "-inf" and
"nan" on all platforms. 

>>> float("inf")
inf
>>> float("-inf")
-inf
>>> float("nan")
nan
>>> repr(1e300 * 1e300)
'inf'
>>> repr(1e300 * 1e300 * 0)
'nan'
>>> repr(1e300 * 1e300 * -1)
'-inf'

----------
assignee: tiran
files: trunk_float_inf_nan.patch
keywords: patch, py3k
messages: 58661
nosy: tiran
priority: normal
severity: normal
status: open
title: Float patch for inf and nan on Windows (and other platforms)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8961/trunk_float_inf_nan.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1635>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_float_inf_nan.patch
Type: text/x-diff
Size: 6764 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071215/c20b6e94/attachment-0001.patch 

From report at bugs.python.org  Sun Dec 16 02:19:19 2007
From: report at bugs.python.org (Jack Atkinson)
Date: Sun, 16 Dec 2007 01:19:19 -0000
Subject: [New-bugs-announce] [issue1636] Execfile unable to take arguments
	beyond 255!
Message-ID: <1197767959.22.0.840307964309.issue1636@psf.upfronthosting.co.za>


New submission from Jack Atkinson:

I found this problem while using PySNMP and trying to load a custom MIB
converted to python code.  Inside the PySNMP, it uses execfile() to load
the python MIBs, and I assume so it won't be put into a separate
namespace.  On one particular MIB, which I cannot modify because it's a
company product MIB, this error of unable to take in more than 255
arguments occurs.  The problem line is quite long, but surely in this
day and age of 32 bit to 64 bit machines this 255 constraint could be
done away with in the execfile function.  I'm assuming the 255
constraint has something to do with unsigned 8 bit number.

----------
components: Interpreter Core
messages: 58668
nosy: jgatkinsn
severity: normal
status: open
title: Execfile unable to take arguments beyond 255!
type: rfe
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1636>
__________________________________

From report at bugs.python.org  Sun Dec 16 18:29:43 2007
From: report at bugs.python.org (John Nagle)
Date: Sun, 16 Dec 2007 17:29:43 -0000
Subject: [New-bugs-announce] [issue1637] urlparse.urlparse misparses URLs
	with query but no path
Message-ID: <1197826183.87.0.566921252289.issue1637@psf.upfronthosting.co.za>


Changes by John Nagle:


----------
components: Library (Lib)
nosy: nagle
severity: normal
status: open
title: urlparse.urlparse misparses URLs with query but no path
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1637>
__________________________________

From report at bugs.python.org  Sun Dec 16 21:22:53 2007
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Sun, 16 Dec 2007 20:22:53 -0000
Subject: [New-bugs-announce] [issue1638] %zd configure test fails on Linux
Message-ID: <1197836573.7.0.318332454178.issue1638@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

The printf("%zd", ...) configure test fails on Linux, although it
supports the %zd format.  config.log reveals that the test tests for %zd
with Py_ssize_t, which is (within the test) typedeffed to ssize_t.  But
the appropriate system header is not included by the test, and ssize_t
is not defined.  This results in Py_ssize_t not being correctly defined,
and the test failing.

According to http://tinyurl.com/3dhbbm/, ssize_t is defined in
<sys/types.h>.  Adding #include <sys/types.h> manually to the test fixes
the test for me.  A patch like the one attached should fix the problem.

----------
files: patch
messages: 58675
nosy: hniksic
severity: normal
status: open
title: %zd configure test fails on Linux
versions: Python 2.5
Added file: http://bugs.python.org/file8966/patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1638>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 248 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071216/9080a5bd/attachment.obj 

From report at bugs.python.org  Mon Dec 17 13:21:26 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Mon, 17 Dec 2007 12:21:26 -0000
Subject: [New-bugs-announce] [issue1639] Low ascii 12 characters found in
	source.
Message-ID: <1197894086.0.0.139723441011.issue1639@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

There were various files in the source tree that contained low ascii 12
characters throughout.  The list includes:

url: http://svn.python.org/projects/python/branches/py3k
rev: 59539
files:
  _ctypes.c
  cfield.c
  _tkinter.c
  stringobject.c

----------
components: Interpreter Core
files: ascii12sPy3k.patch
messages: 58689
nosy: JosephArmbruster
severity: normal
status: open
title: Low ascii 12 characters found in source.
versions: Python 3.0
Added file: http://bugs.python.org/file8973/ascii12sPy3k.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1639>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ascii12sPy3k.patch
Type: application/octet-stream
Size: 5506 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071217/e29caf57/attachment.obj 

From report at bugs.python.org  Mon Dec 17 16:48:44 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Dec 2007 15:48:44 -0000
Subject: [New-bugs-announce] [issue1640] Enhancements for mathmodule
Message-ID: <1197906524.11.0.494722426175.issue1640@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch adds several small enhancements to the math module and pyport.h.

* Py_MATH_PI and Py_MATH_E in long double precision
* Py_IS_NAN and Py_IS_INFINITY use isnan() and isinf() functions were
available (checked by configure)
* isnan and isinf for the math module
* Bessel (1st and 2nd kind), erf, erfc, lgamma function for math module.
They are defined in almost (or all?) math libraries.

Together with http://bugs.python.org/issue1635 it implements most of PEP
754.

----------
components: Extension Modules
files: trunk_mathmodule.patch
keywords: patch
messages: 58694
nosy: tiran
priority: normal
severity: normal
status: open
title: Enhancements for mathmodule
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8975/trunk_mathmodule.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1640>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_mathmodule.patch
Type: text/x-diff
Size: 20978 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071217/30f5d150/attachment-0001.patch 

From report at bugs.python.org  Mon Dec 17 17:24:53 2007
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 Dec 2007 16:24:53 -0000
Subject: [New-bugs-announce] [issue1641] asyncore delayed calls feature
Message-ID: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

Hi,
I post this message here in the hope someone using asyncore could review
this.
Since the thing I miss mostly in asyncore is a system for calling a
function after a certain amount of time, I spent the last 3 days trying
to implement this with the hopes that this could be included in asyncore
in the the future.
The logic consists in calling a certain function (the "scheduler") at
every loop to check if it is the proper time to call one or more
scheduled functions.
Such functions are scheduled by the new delayed_call class which is very
similar to the DelayedCall class defined in /twisted/internet/base.py I
drew on.
It provides a basic API which can be used for setting, resetting and
canceling the scheduled functions.
For better performance I used an heap queue structure. This way the
scheduler() only needs to check the scheduled functions due to expire
soonest.

The following code sample implements an idle-timeout capability using
the attached modified asyncore library.

--- code snippet ---
import asyncore, asynchat, socket

class foo(asynchat.async_chat):

   def __init__(self, conn=None):
       asynchat.async_chat.__init__(self, conn)
       self.set_terminator(None)
       self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
       self.connect(('127.0.0.1', 21))
       self.scheduled_timeout = self.call_later(120, self.handle_timeout)

   def collect_incoming_data(self, data):
       self.scheduled_timeout.reset()
       # do something with the data...

   def handle_timeout(self):
       self.push("500 Connection timed out.\r\n")
       self.close_when_done()
       
   def close(self):
       if not self.scheduled_timeout.cancelled:
           self.scheduled_timeout.cancel()
       asyncore.dispatcher.close(self)

foo()
asyncore.loop()
--- /code snippet ---


Today I played a little more with it and I tried to add bandwidth
throttling capabilities to the base asynchat.py.
The code could be surely improved but it's just an example to show
another useful feature which wouldn't be possible to implement without
having a "call_later" function under the hood:


--- code snippet ---
class throttled_async_chat(asynchat.async_chat):
    # maximum number of bytes to transmit in a second (0 == no limit)
    read_limit = 100 * 1024
    write_limit = 100 * 1024

    # smaller the buffers, the less bursty and smoother the throughput
    ac_in_buffer_size = 2048
    ac_out_buffer_size  = 2048

    def __init__(self, conn=None):
        asynchat.async_chat.__init__(self, conn)
        self.read_this_second = 0
        self.written_this_second = 0
        self.r_timenext = 0
        self.w_timenext = 0
        self.r_sleep = False
        self.w_sleep = False
        self.delayed_r = None
        self.delayed_w = None

    def readable(self):
        return asynchat.async_chat.readable(self) and not self.r_sleep

    def writable(self):
        return asynchat.async_chat.writable(self) and not self.w_sleep

    def recv(self, buffer_size):
        chunk = asyncore.dispatcher.recv(self, buffer_size)
        if self.read_limit:
            self.read_this_second += len(chunk)
            self.throttle_read()
        return chunk

    def send(self, data):
        num_sent = asyncore.dispatcher.send(self, data)
        if self.write_limit:
            self.written_this_second += num_sent
            self.throttle_write()
        return num_sent

    def throttle_read(self):
        if self.read_this_second >= self.read_limit:
            self.read_this_second = 0
            now = time.time()
            sleepfor = self.r_timenext - now
            if sleepfor > 0:
                # we've passed bandwidth limits
                self.r_sleep = True
                def unthrottle():
                    self.r_sleep = False
                self.delayed_r = self.call_later((sleepfor * 2), unthrottle)
            self.r_timenext = now + 1

    def throttle_write(self):
        if self.written_this_second >= self.write_limit:
            self.written_this_second = 0
            now = time.time()
            sleepfor = self.w_timenext - now
            if sleepfor > 0:
                # we've passed bandwidth limits
                self.w_sleep = True
                def unthrottle():
                    self.w_sleep = False
                self.delayed_w = self.call_later((sleepfor * 2), unthrottle)
            self.w_timenext = now + 1

    def close(self):
        if self.delayed_r and not self.delayed_r.cancelled:
            self.delayed_r.cancel()
        if self.delayed_w and not self.delayed_w.cancelled:
            self.delayed_w.cancel()
        asyncore.dispatcher.close(self)
--- /code snippet ---


I don't know if there's a better way to implement this "call_later" feature.
Maybe someone experienced with Twisted could provide a better approach.
I would ask someone using asyncore to review this since, IMHO, it would
fill a very big gap.

----------
components: Library (Lib)
messages: 58695
nosy: giampaolo.rodola, josiahcarlson
severity: normal
status: open
title: asyncore delayed calls feature
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
__________________________________

From report at bugs.python.org  Mon Dec 17 20:58:19 2007
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Mon, 17 Dec 2007 19:58:19 -0000
Subject: [New-bugs-announce] [issue1642] segfault when deleting value member
	in ctypes types
Message-ID: <1197921499.01.0.370376997036.issue1642@psf.upfronthosting.co.za>


New submission from Carl Friedrich Bolz:

When trying to delete the .value member of ctypes simple types my python
interpreter segfaults:

$ python
Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import c_long
>>> c = c_long(1)
>>> c.value
1
>>> del c.value
Segmentation fault (core dumped)


Admittedly there is no good usecase for this, but it should raise an
exception and not segfault.

----------
components: Extension Modules
messages: 58705
nosy: cfbolz
severity: normal
status: open
title: segfault when deleting value member in ctypes types
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1642>
__________________________________

From report at bugs.python.org  Tue Dec 18 02:49:19 2007
From: report at bugs.python.org (Kirk McDonald)
Date: Tue, 18 Dec 2007 01:49:19 -0000
Subject: [New-bugs-announce] [issue1643] Add group() to itertools
Message-ID: <1197942559.18.0.611472238589.issue1643@psf.upfronthosting.co.za>


New submission from Kirk McDonald:

One question which is asked with surprising frequency in #python is how
to yield multiple objects at a time from an iterable object. That is,
given [1, 2, 3, 4, 5, 6], get [(1, 2), (3, 4), (5, 6)]. 

The "grouper" function in the itertools recipes page provides one
pattern for this. A similar function (which behaves differently when the
length of the iterable is not evenly divisible by n) looks like this:

def group(iterable, n=2):
    return itertools.izip(*(iter(iterable),)*n)

This code is fairly opaque to the novice. It is ugly, and takes a bit of
head-scratching to realize exactly what it is doing. Because this
operation is asked for with some frequency, and because this general
implementation is so ugly, I believe it belongs in the library.

There is a related function which is asked for much less frequently, but
which is a more general case of the group() function listed above. This
other function has a third "step" argument. This argument controls how
far each group is in advance of the previous group. For example:

list(group([1, 2, 3, 4], n=2, step=1)) -> [(1, 2), (2, 3), (3, 4)]

The original function is equivalent to this function when step is equal
to n.

Please find attached a patch with implementation, documentation, and tests.

----------
components: Library (Lib)
files: itertools.group.patch
messages: 58716
nosy: KirkMcDonald
severity: normal
status: open
title: Add group() to itertools
versions: Python 2.6
Added file: http://bugs.python.org/file8979/itertools.group.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1643>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itertools.group.patch
Type: application/octet-stream
Size: 8427 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071218/bd4b3467/attachment.obj 

From report at bugs.python.org  Tue Dec 18 03:49:47 2007
From: report at bugs.python.org (Alberto Bertogli)
Date: Tue, 18 Dec 2007 02:49:47 -0000
Subject: [New-bugs-announce] [issue1644] Patch submission guidelines outdated
Message-ID: <1197946187.26.0.374673347537.issue1644@psf.upfronthosting.co.za>


New submission from Alberto Bertogli:

The FAQ section 5.4, "How to submit a patch?", points to
http://www.python.org/patches/, which looks really outdated
(plus the sf page seems to be restricted to members only).

Thanks,
    Alberto

----------
components: Documentation
messages: 58719
nosy: albertito
severity: normal
status: open
title: Patch submission guidelines outdated

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644>
__________________________________

From report at bugs.python.org  Tue Dec 18 03:52:26 2007
From: report at bugs.python.org (Alberto Bertogli)
Date: Tue, 18 Dec 2007 02:52:26 -0000
Subject: [New-bugs-announce] [issue1645] Fix
	socketmodule.c:sock_recvfrom_guts() comment.
Message-ID: <1197946346.54.0.433322957644.issue1645@psf.upfronthosting.co.za>


New submission from Alberto Bertogli:

The comment above sock_recvfrom_guts() was copied from sock_recv_guts() and
referenced recv() and recv_into() when it should be talking about recvfrom()
and recvfrom_into().

The attached patch (against trunk) fixes it.

----------
components: Library (Lib)
files: 0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch
messages: 58720
nosy: albertito
severity: minor
status: open
title: Fix socketmodule.c:sock_recvfrom_guts() comment.
versions: Python 2.6
Added file: http://bugs.python.org/file8980/0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1645>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch
Type: text/x-patch
Size: 1566 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071218/d067bb02/attachment-0001.bin 

From report at bugs.python.org  Tue Dec 18 03:54:12 2007
From: report at bugs.python.org (Alberto Bertogli)
Date: Tue, 18 Dec 2007 02:54:12 -0000
Subject: [New-bugs-announce] [issue1646] Make socket support TIPC.
Message-ID: <1197946452.07.0.0208119521278.issue1646@psf.upfronthosting.co.za>


New submission from Alberto Bertogli:

TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.

The attached patch (against trunk) adds optional Linux-only support for
TIPC in the socket module.

If you want me to make one against 3.0 or any other branch, just let me
know.

Thanks,
    Alberto

----------
components: Library (Lib)
files: 0002-Make-socket-support-TIPC.patch
messages: 58721
nosy: albertito
severity: normal
status: open
title: Make socket support TIPC.
versions: Python 2.6
Added file: http://bugs.python.org/file8981/0002-Make-socket-support-TIPC.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Make-socket-support-TIPC.patch
Type: text/x-patch
Size: 7446 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071218/5f9e16f9/attachment.bin 

From report at bugs.python.org  Tue Dec 18 04:29:12 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Dec 2007 03:29:12 -0000
Subject: [New-bugs-announce] [issue1647] IDLE messes around with sys.exitfunc
Message-ID: <1197948552.45.0.790109797324.issue1647@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Is it necessary to alter or remove the exit function?

c:\dev\python\trunk\PCbuild9>python ..\Lib\idlelib\idle.py
Traceback (most recent call last):
  File "c:\dev\python\trunk\lib\idlelib\run.py", line 83, in main
    exit()
  File "c:\dev\python\trunk\lib\idlelib\run.py", line 209, in exit
    del sys.exitfunc
AttributeError: exitfunc

----------
assignee: kbk
components: IDLE
messages: 58722
nosy: kbk, tiran
severity: normal
status: open
title: IDLE messes around with sys.exitfunc
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647>
__________________________________

From report at bugs.python.org  Tue Dec 18 08:16:46 2007
From: report at bugs.python.org (Titus Brown)
Date: Tue, 18 Dec 2007 07:16:46 -0000
Subject: [New-bugs-announce] [issue1648] add new function, sys.gettrace
Message-ID: <1197962206.78.0.66019854769.issue1648@psf.upfronthosting.co.za>


New submission from Titus Brown:

Currently there is no way to retrieve the current trace function; this
patch adds 'gettrace' to the sys module.

This behavior is very useful for helping to control code coverage
analysis tools.

----------
components: Library (Lib)
files: gettrace.diff
messages: 58725
nosy: brett.cannon, titus
severity: minor
status: open
title: add new function, sys.gettrace
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8982/gettrace.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1648>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gettrace.diff
Type: application/octet-stream
Size: 2659 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071218/f8708d8a/attachment.obj 

From report at bugs.python.org  Tue Dec 18 10:03:33 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Dec 2007 09:03:33 -0000
Subject: [New-bugs-announce] [issue1649] IDLE error: dictionary changed size
	during iteration
Message-ID: <1197968613.72.0.593763152218.issue1649@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This happens when I press on X to close idle:

c:\dev\python\trunk\PCbuild9>python ../Lib/idlelib/idle.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\dev\python\trunk\lib\lib-tk\Tkinter.py", line 1403, in __call__
    return self.func(*args)
  File "c:\dev\python\trunk\lib\lib-tk\Tkinter.py", line 498, in callit
    func(*args)
  File "c:\dev\python\trunk\lib\idlelib\PyShell.py", line 945, in close2
    return EditorWindow.close(self)
  File "c:\dev\python\trunk\lib\idlelib\EditorWindow.py", line 825, in close
    self._close()
  File "c:\dev\python\trunk\lib\idlelib\PyShell.py", line 961, in _close
    EditorWindow._close(self)
  File "c:\dev\python\trunk\lib\idlelib\EditorWindow.py", line 841, in
_close
    self.per.close()
  File "c:\dev\python\trunk\lib\idlelib\Percolator.py", line 20, in close
    self.redir.close(); self.redir = None
  File "c:\dev\python\trunk\lib\idlelib\WidgetRedirector.py", line 43,
in close
    for operation in self._operations:
RuntimeError: dictionary changed size during iteration

Windows XP, Python 2.6 trunk, Tcl 8.4.16 (corrected build).

----------
assignee: kbk
components: IDLE, Windows
messages: 58730
nosy: kbk, tiran
priority: normal
severity: normal
status: open
title: IDLE error: dictionary changed size during iteration
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649>
__________________________________

From report at bugs.python.org  Tue Dec 18 10:29:30 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Dec 2007 09:29:30 -0000
Subject: [New-bugs-announce] [issue1650] IDLE: help() displays output on the
	wrong shell
Message-ID: <1197970170.0.0.124909040304.issue1650@psf.upfronthosting.co.za>


New submission from Christian Heimes:

On Python 3.0 IDLE shows the output of help() on the system shell that
started IDLE and not inside the IDLE window.

----------
assignee: kbk
components: IDLE, Windows
messages: 58732
nosy: kbk, tiran
priority: normal
severity: normal
status: open
title: IDLE: help() displays output on the wrong shell
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1650>
__________________________________

From report at bugs.python.org  Tue Dec 18 13:13:40 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Dec 2007 12:13:40 -0000
Subject: [New-bugs-announce] [issue1651] Limit the max size of
	PyUnicodeObject->defenc?
Message-ID: <1197980020.78.0.710337047822.issue1651@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I think that the cached default encoding version of the unicode object
should be limited in size. It's probably a bad idea to cache a 100MB of
data. For large amount strings and unicode objects the user should do
explicit caching if required.

----------
components: Interpreter Core
keywords: patch, py3k
messages: 58744
nosy: tiran
priority: high
severity: normal
status: open
title: Limit the max size of PyUnicodeObject->defenc?
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1651>
__________________________________

From report at bugs.python.org  Tue Dec 18 16:41:06 2007
From: report at bugs.python.org (Colin Watson)
Date: Tue, 18 Dec 2007 15:41:06 -0000
Subject: [New-bugs-announce] [issue1652] subprocess should have an option to
	restore SIGPIPE to default action
Message-ID: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>


New submission from Colin Watson:

On Unix, Python sets SIGPIPE to SIG_IGN on startup, because it prefers
to check every write and raise an IOError exception rather than taking
SIGPIPE. This is all well and good for Python itself. However,
non-Python Unix subprocesses generally expect to have SIGPIPE set to the
default action, since that's what will happen if they're started from a
normal shell. If this is not the case, then rather than taking SIGPIPE
when a write fails due to the reading end of a pipe having been closed,
write will return EPIPE and it's up to the process to check that. Many
programs are lazy and fail to check for write errors, but in the
specific case of pipe closure they are fine when invoked from a normal
shell because they rely on taking the signal. Even correctly written
programs that diligently check for write errors will typically produce
different (and confusing) output when SIGPIPE is ignored. For instance,
an example only very slightly adapted from one in the subprocess
documentation:

  $ dd if=/dev/zero of=bigfile bs=1024 seek=10000 count=1
  1+0 records in
  1+0 records out
  1024 bytes (1.0 kB) copied, 0.000176709 seconds, 5.8 MB/s
  $ cat bigfile | head -n0
  $ cat t.py
  from subprocess import Popen, PIPE
  p1 = Popen(["cat", "bigfile"], stdout=PIPE)
  p2 = Popen(["head", "-n0"], stdin=p1.stdout, stdout=PIPE)
  output = p2.communicate()[0]
  $ python t.py
  cat: write error: Broken pipe

In some cases this problem can be much more significant. For instance,
it is very common for shell scripts to rely on SIGPIPE's default action
in order to behave correctly. A year or two ago I ran into this in OS
installer code I was writing in Python, which called some underlying
utility code in shell and C to deal with disk partitioning. In the event
that the Python code failed to handle an exception, the shell script
being run in a subprocess would spiral out of control rather than
cleanly exiting at the first sign of trouble. This actually caused
massive data loss on several testers' systems and required a quick
release to fix
(https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/40464 and
https://wiki.ubuntu.com/DapperBeta/PartitionTableCorruption). Now
obviously this was ultimately my fault for failing to catch the
exceptional condition in testing, but this misdesign in Python and the
lack of any documentation of this gotcha really didn't help at the time.
For the record, the fix was to call this in a preexec_fn:

  signal.signal(signal.SIGPIPE, signal.SIG_DFL)

This is an area of Unix that's very easy to get wrong. I've written my
own subprocess handling library in C for another project, and I still
found it non-trivial to track this down when it bit me. Since it
essentially arises due to an implementation detail of the Python
language, I think it should also be Python's responsibility to fix it up
when subprocesses are involved.

There are many ways to invoke subprocesses in Python, but the new,
all-singing, all-dancing one is of course the subprocess module. I think
it would be sufficient for that to do the right thing, or at least have
an option to do so, and it's certainly the easiest place to add the
option. I'm attaching a suggested patch which adds a restore_sigpipe
option and documents it in what seem to be all the relevant places.

Note that nearly all the examples end up with restore_sigpipe enabled.
In some future release of Python, I think this should be the default.
I'm not entirely familiar with migration plan processes in Python; how
should this be done?

----------
components: Library (Lib)
files: subprocess-sigpipe.patch
messages: 58750
nosy: cjwatson
severity: normal
status: open
title: subprocess should have an option to restore SIGPIPE to default action
versions: Python 2.5
Added file: http://bugs.python.org/file8986/subprocess-sigpipe.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subprocess-sigpipe.patch
Type: text/x-patch
Size: 13142 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071218/3d66482a/attachment.bin 

From report at bugs.python.org  Tue Dec 18 18:46:38 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Tue, 18 Dec 2007 17:46:38 -0000
Subject: [New-bugs-announce] [issue1653] a couple of  documentation issues
Message-ID: <1197999998.22.0.922085373773.issue1653@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

I added an option to msi.py (and a support script) that allows the user
to optionally decompile the python30.chm post installation.  In doing
so, I was testing out help() from the interpreter and stumbled upon a
few things that I think are issues.  One of the ways I experimented, was
by typing the following commands at the interpreter, to see what I could
pull up on the global statement:
   help()
   keywords
   global

I had run into the following issues on my way.  Additional eyes /
insight would definitely be helpful.  Just a couple forewords:
- os.environ.get("PYTHONDOCS") returns 'C:\\Python30\\Doc'
- my version of the installer decompiled the Python30.chm as dictated by
pydoc.  So that, c:\Python30\Doc has folders c-api, data, distutils, etc..

If I missed anything basic with these, my apologies in advanced. 

Issue 1: PYTHONDOCS does not appear to be respected.

  * I generated python-3.0.13865.msi and installed
  * post-install I set PYTHONDOCS to C:\python30\doc
  * I fired up a new command prompt
  * Fire up Python3k interpreter and attempt the help() session listed
above.
  * I had to hack at pydoc.py, since the #windows statement never gets
reached.

        join = os.path.join
        if sys.platform=='win32':           #hack
            self.docdir=join(execdir,'doc') #...
        else:                               #...
            for dir in [os.environ.get('PYTHONDOCS'),
                    homedir and os.path.join(homedir, 'doc'),
                    join(execdir, 'doc'), # for Windows

Issue 2: pydoc.py class Helper member keywords contain several invalid
paths.  For instance:

        'global': ('ref/global', 'NAMESPACES'),

Most of the keywords appear to have the ref/ prefixes.

Issue 3:  formatter.py will throw an exception within push_margin /
pop_margin on the lines where a len(fstack) is attempted.  The two lines
look like this:

        self.writer.new_margin(margin, len(fstack))

I do not have a patch for this, since i'm still wandering about through
the whole installer generation stuffs.  When I get home, I will examine
further.

Thoughts?

----------
components: Documentation, Windows
messages: 58751
nosy: JosephArmbruster, loewis, tiran
severity: normal
status: open
title: a couple of  documentation issues
type: crash
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653>
__________________________________

From report at bugs.python.org  Tue Dec 18 21:52:12 2007
From: report at bugs.python.org (Derek Morr)
Date: Tue, 18 Dec 2007 20:52:12 -0000
Subject: [New-bugs-announce] [issue1654] HTTPSConnection is not IPv6-capable
Message-ID: <1198011132.22.0.859513057962.issue1654@psf.upfronthosting.co.za>


New submission from Derek Morr:

httplib.HTTPSConnection is not IPv6-capable, even though
httplib.HTTPConnection is. HTTPSConnection has its own connect() method
which does not call socket.getaddrinfo().

----------
components: Library (Lib)
messages: 58769
nosy: dmorr
severity: normal
status: open
title: HTTPSConnection is not IPv6-capable
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1654>
__________________________________

From report at bugs.python.org  Tue Dec 18 22:34:58 2007
From: report at bugs.python.org (Derek Morr)
Date: Tue, 18 Dec 2007 21:34:58 -0000
Subject: [New-bugs-announce] [issue1655] imaplib is not IPv6-capable
Message-ID: <1198013698.88.0.631907928895.issue1655@psf.upfronthosting.co.za>


New submission from Derek Morr:

imaplib.IMAP4 and IMAP4_SSL do not use IPv6-capable name resolution
APIs. Attached is a patch (lifted from httplib) that enables IPv6 in
their open() methods.

----------
components: Library (Lib)
files: imaplib_ipv6.patch
messages: 58775
nosy: dmorr
severity: normal
status: open
title: imaplib is not IPv6-capable
versions: Python 2.5
Added file: http://bugs.python.org/file8987/imaplib_ipv6.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1655>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imaplib_ipv6.patch
Type: application/octet-stream
Size: 1840 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071218/a2dd26c4/attachment.obj 

From report at bugs.python.org  Wed Dec 19 05:39:35 2007
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 19 Dec 2007 04:39:35 -0000
Subject: [New-bugs-announce] [issue1656] Make math.{floor,
	ceil}(float) return ints per PEP 3141
Message-ID: <1198039175.03.0.481306774301.issue1656@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

See
http://python.org/dev/peps/pep-3141/#changes-to-operations-and-magic-methods

----------
components: Library (Lib)
files: floorceil_return_int.patch
messages: 58792
nosy: jyasskin
severity: normal
status: open
title: Make math.{floor,ceil}(float) return ints per PEP 3141
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8990/floorceil_return_int.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1656>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: floorceil_return_int.patch
Type: application/octet-stream
Size: 2722 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/05fe6fe4/attachment.obj 

From report at bugs.python.org  Wed Dec 19 07:57:08 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 19 Dec 2007 06:57:08 -0000
Subject: [New-bugs-announce] [issue1657] [patch] select.epoll wrapper for
	Linux 2.6 epoll()
Message-ID: <1198047428.24.0.557544624136.issue1657@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch implements Linux's epoll interface
(http://linux.die.net/man/4/epoll). My patch doesn't introduce a new
module like http://bugs.python.org/issue1675118 and it wraps the epoll
control fd in an object like Twisted's _epoll.pyd interface.

My interface is almost identical to Twisted's API except for some names.
I named my control function "control" instead of "_control" and the
constants are all named "select.EPOLL_SPAM" instead of "SPAM".

Missing:
Documentation

----------
assignee: tiran
files: trunk_select_epoll.patch
keywords: patch, py3k
messages: 58795
nosy: tiran
priority: normal
severity: normal
status: open
title: [patch] select.epoll wrapper for Linux 2.6 epoll()
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8992/trunk_select_epoll.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_select_epoll.patch
Type: text/x-diff
Size: 18182 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/a835256e/attachment-0001.patch 

From report at bugs.python.org  Wed Dec 19 14:08:17 2007
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Wed, 19 Dec 2007 13:08:17 -0000
Subject: [New-bugs-announce] [issue1658] "RuntimeError: dictionary changed
	size during iteration" in Tkinter
Message-ID: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>


New submission from Quentin Gallet-Gilles:

While investigating for the stdlib reorg of Tkinter, I came across the
following error:

~/dev/py3k$ ./python Lib/lib-tk/Dialog.py 
Traceback (most recent call last):
  File "Lib/lib-tk/Dialog.py", line 45, in <module>
    Pack: {}})
  File "/home/quentin/dev/py3k/Lib/lib-tk/Tkinter.py", line 1996, in
__init__
    Widget.__init__(self, master, 'button', cnf, kw)
  File "/home/quentin/dev/py3k/Lib/lib-tk/Tkinter.py", line 1921, in
__init__
    for k in cnf.keys():
RuntimeError: dictionary changed size during iteration


The attached patch adds list() around the dict.keys() call.

On a related note, this doesn't appear to be an isolated error, since a
similar issue (#1649) was recently fixed in r59554. Would it be a good
idea to look for other identical cases ?

----------
components: Tkinter
files: tkinter_dictkeys.patch
messages: 58805
nosy: quentin.gallet-gilles
severity: normal
status: open
title: "RuntimeError: dictionary changed size during iteration" in Tkinter
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file8995/tkinter_dictkeys.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1658>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tkinter_dictkeys.patch
Type: text/x-patch
Size: 485 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/4b436496/attachment.bin 

From report at bugs.python.org  Wed Dec 19 16:17:30 2007
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 19 Dec 2007 15:17:30 -0000
Subject: [New-bugs-announce] [issue1659] Tests needing network flag?
Message-ID: <18281.12938.264352.782990@montanaro.dyndns.org>


New submission from Skip Montanaro:

While riding to work today I ran the test suite on trunk.  The following
tests failed due to lack of network connectivity:

    test_socket
    test_socket_ssl
    test_ssl
    test_urllib2

These tests should probably either require -u network or should themselves
check to see if the network is available and skip those tests requiring
network connectivity.  In fact, regrtest.py's comments list test_socket_ssl
as requiring the network resource.  That seems to have regressed since 2.5

Simple patch attached.

Skip

----------
files: network.diff
messages: 58806
nosy: skip.montanaro
severity: normal
status: open
title: Tests needing network flag?
Added file: http://bugs.python.org/file8996/network.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1659>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network.diff
Type: application/octet-stream
Size: 1908 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/0a1679e3/attachment.obj 

From report at bugs.python.org  Wed Dec 19 16:18:36 2007
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 19 Dec 2007 15:18:36 -0000
Subject: [New-bugs-announce] [issue1660] Tests needing network flag?
Message-ID: <18281.13328.791924.902780@montanaro.dyndns.org>


New submission from Skip Montanaro:

(third try at getting this bug report to submit by email.)

While riding to work today I ran the test suite on trunk.  The following
tests failed due to lack of network connectivity:

    test_socket
    test_socket_ssl
    test_ssl
    test_urllib2

These tests should probably either require -u network or should themselves
check to see if the network is available and skip those tests requiring
network connectivity.  In fact, regrtest.py's comments list test_socket_ssl
as requiring the network resource.  That seems to have regressed since 2.5

Simple patch attached.

Skip

----------
files: network.diff
messages: 58807
nosy: skip.montanaro
severity: normal
status: open
title: Tests needing network flag?
Added file: http://bugs.python.org/file8997/network.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1660>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network.diff
Type: application/octet-stream
Size: 1908 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/4e8be30c/attachment.obj 

From report at bugs.python.org  Wed Dec 19 16:40:03 2007
From: report at bugs.python.org (Brandon Corfman)
Date: Wed, 19 Dec 2007 15:40:03 -0000
Subject: [New-bugs-announce] [issue1661] re.match ignores optional flags
	when receiving a compiled regex pattern
Message-ID: <1198078803.93.0.586517631888.issue1661@psf.upfronthosting.co.za>


New submission from Brandon Corfman:

Python's documentation for the re.match function is match(pattern,
string, [flags]) where pattern can be either a regex string or a
compiled regex object. If it's a compiled regex object, then supplying
an optional flag to re.match (in my case, re.IGNORECASE) doesn't work
and, more to the point, fails silently. I think this should throw an
exception if it's not going to work.

See
http://mysite.verizon.net/bcorfman/2007/12/something-i-hate-about-pythons-re.html
for a discussion.

A possible change (proposed by effbot) is below:
Index: re.py
===================================================================
--- re.py       (revision 52330)
+++ re.py       (working copy)
@@ -224,6 +224,7 @@
         return p
     pattern, flags = key
     if isinstance(pattern, _pattern_type):
+        assert not flags
         return pattern
     if not sre_compile.isstring(pattern):
         raise TypeError, "first argument must be string or compiled
pattern"

----------
components: Regular Expressions
messages: 58808
nosy: bcorfman
severity: normal
status: open
title: re.match ignores optional flags when receiving a compiled regex pattern
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1661>
__________________________________

From report at bugs.python.org  Wed Dec 19 18:22:01 2007
From: report at bugs.python.org (Bryan Silverthorn)
Date: Wed, 19 Dec 2007 17:22:01 -0000
Subject: [New-bugs-announce] [issue1662] [patch] assert tp_traverse in
	PyType_GenericAlloc()
Message-ID: <1198084921.68.0.0736452990224.issue1662@psf.upfronthosting.co.za>


New submission from Bryan Silverthorn:

Attached is a very short patch against r59568 which asserts tp_traverse
on (the types of) objects allocated in PyType_GenericAlloc(). As far as
I'm aware, tp_traverse should always be set at this point. Catching that
error early, even if only in debug builds, would help to prevent bugs
like http://bugzilla.gnome.org/show_bug.cgi?id=504337 .

----------
components: Interpreter Core
files: bcs_typeobject_assert.patch
messages: 58811
nosy: bsilverthorn
severity: minor
status: open
title: [patch] assert tp_traverse in PyType_GenericAlloc()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8998/bcs_typeobject_assert.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bcs_typeobject_assert.patch
Type: text/x-patch
Size: 406 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/e4bc073e/attachment.bin 

From report at bugs.python.org  Wed Dec 19 21:05:21 2007
From: report at bugs.python.org (diego)
Date: Wed, 19 Dec 2007 20:05:21 -0000
Subject: [New-bugs-announce] [issue1663] Modification HTMLParser.py
Message-ID: <1198094721.16.0.0968009293382.issue1663@psf.upfronthosting.co.za>


New submission from diego:

Hello my name is Diego, I needed to parse HTML to retrieve only text,
but not grasped how to do it with class HTMLParser, so the change to do
it. The code to use is:
class ParsearHTML (HTMLParser.HTMLParser):

    def __init__(self,datos):
        HTMLParser.HTMLParser.__init__(self)
        self.feed(datos)
        self.close()

    def handle_data(self,data):
        return data

parser  = ParsearHTML(onTmp)
data = parser.feed(onTmp)
And changes in the class are attached. Thank you very much. Diego.

----------
components: None
files: HTMLParser.py
messages: 58821
nosy: diegorubenarias
severity: normal
status: open
title: Modification HTMLParser.py
type: resource usage
versions: Python 2.4
Added file: http://bugs.python.org/file9000/HTMLParser.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1663>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HTMLParser.py
Type: text/x-python
Size: 13168 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/a0ea41b2/attachment-0001.py 

From report at bugs.python.org  Wed Dec 19 21:07:10 2007
From: report at bugs.python.org (Derek Morr)
Date: Wed, 19 Dec 2007 20:07:10 -0000
Subject: [New-bugs-announce] [issue1664] nntplib is not IPv6-capable
Message-ID: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za>


New submission from Derek Morr:

nntplib hardcodes AF_INET for the socket address family. This prevents
it from using IPv6. Attached is a patch that converts NNTP.__init__() to
use socket.create_connection(), which is IPv6-capable.

----------
components: Library (Lib)
files: nntplib_ipv6.patch
messages: 58822
nosy: dmorr
severity: normal
status: open
title: nntplib is not IPv6-capable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9001/nntplib_ipv6.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1664>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nntplib_ipv6.patch
Type: application/octet-stream
Size: 540 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071219/c771ccf4/attachment.obj 

From report at bugs.python.org  Wed Dec 19 23:55:20 2007
From: report at bugs.python.org (thekorn)
Date: Wed, 19 Dec 2007 22:55:20 -0000
Subject: [New-bugs-announce] [issue1665] re.match.func_code.co_filename
	returns "re.py"
Message-ID: <1198104920.19.0.210169146958.issue1665@psf.upfronthosting.co.za>


Changes by thekorn:


----------
components: None
nosy: thekorn
severity: normal
status: open
title: re.match.func_code.co_filename returns "re.py"
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665>
__________________________________

From report at bugs.python.org  Thu Dec 20 04:39:42 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 20 Dec 2007 03:39:42 -0000
Subject: [New-bugs-announce] [issue1666] integer subclass range behavior
Message-ID: <1198121982.55.0.188898496542.issue1666@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

I was wondering what would happen, so I tried this out for the heck of
it with:

Python 3.0a2 (py3k:59572M, Dec 19 2007, 15:54:07) [MSC v.1500 32 bit
(Intel)]
on win32

class a(int):
   def __new__(cls,number):
     return int.__new__(cls,number)
for x in range(0,a(5)):
  print(x)


This resulted in a:
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "a.py", line 5, in <module>
     for x in range(0,a(5)):
SystemError: ..\Objects\longobject.c:400: bad argument to internal
function
[41030 refs]

It looks like the rangeobject performs a FitsInLong test on each of
the parameters to range, which uses the function
_PyLong_FitsInLong(PyObject *vv) within longobject.c.  In tern, this
performs a typecheck:  #define PyLong_CheckExact(op) (Py_TYPE(op) ==
&PyLong_Type) that fails.

----------
components: Interpreter Core
messages: 58852
nosy: JosephArmbruster
severity: normal
status: open
title: integer subclass range behavior
type: crash
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666>
__________________________________

From report at bugs.python.org  Thu Dec 20 06:36:59 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 20 Dec 2007 05:36:59 -0000
Subject: [New-bugs-announce] [issue1667] license() does not process keyboard
	input correctly
Message-ID: <1198129018.94.0.275386656073.issue1667@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

url: http://svn.python.org/projects/python/branches/py3k
rev: 59577

The license() function does not appear to process keyboard input
correctly.  Symptoms:
- Carriage returns do not move license pages downwards
- q option did not quit

Patch to site.py attached.

----------
components: Documentation
files: licensepatch.patch
messages: 58857
nosy: JosephArmbruster
severity: normal
status: open
title: license() does not process keyboard input correctly
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9007/licensepatch.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: licensepatch.patch
Type: application/octet-stream
Size: 720 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071220/1e5c8a52/attachment.obj 

From report at bugs.python.org  Thu Dec 20 06:56:17 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 20 Dec 2007 05:56:17 -0000
Subject: [New-bugs-announce] [issue1668] -E command line parameter intent
Message-ID: <1198130177.93.0.716869224734.issue1668@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

url: http://svn.python.org/projects/python/branches/py3k
rev: 59577

The intent of the -E command line parameter is not entirely clear from
it's description.  If it implies that All environment variables will be
ignored then this is not currently the case.  If it implies that a few
select environment variables will be ignored, then this is partially the
case.

See the attached patch for the potentially odd cases.

----------
components: Interpreter Core
files: getenvpatch.patch
messages: 58859
nosy: JosephArmbruster
severity: normal
status: open
title: -E command line parameter intent
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9008/getenvpatch.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1668>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getenvpatch.patch
Type: application/octet-stream
Size: 1044 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071220/04cd1903/attachment.obj 

From report at bugs.python.org  Thu Dec 20 09:53:22 2007
From: report at bugs.python.org (Tim Koopman)
Date: Thu, 20 Dec 2007 08:53:22 -0000
Subject: [New-bugs-announce] [issue1669] shutils.rmtree fails on symlink,
	after deleting contents
Message-ID: <1198140802.03.0.559721880432.issue1669@psf.upfronthosting.co.za>


New submission from Tim Koopman:

When using rmtree with a symlink to a directory as path, it will first
follow the symlink, (try to) remove all the contents of the source
directory and then raise the exception "OSError: [Errno 20] Not a
directory".

Expected behaviour: The function should only raise an exception.

If the current behaviour is indeed wanted, it should a least be documented.

----------
components: Library (Lib)
messages: 58864
nosy: Tesiph
severity: normal
status: open
title: shutils.rmtree fails on symlink, after deleting contents
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669>
__________________________________

From report at bugs.python.org  Thu Dec 20 10:23:05 2007
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 20 Dec 2007 09:23:05 -0000
Subject: [New-bugs-announce] [issue1670] Threading.Condition.wait is
	non-iteruptable
Message-ID: <1198142584.99.0.238062173257.issue1670@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

The scriptlet below hangs (as expected) but is also not interuptable by 
Ctrl+C, at least on Linux and Mac OS X:

from Queue import Queue, Empty, Full

q = Queue()
q.get(True)

This is due to Threading.Condition.wait not being interuptable.

----------
components: Library (Lib)
messages: 58865
nosy: ronaldoussoren
priority: low
severity: minor
status: open
title: Threading.Condition.wait is non-iteruptable
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670>
__________________________________

From report at bugs.python.org  Thu Dec 20 14:30:23 2007
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Thu, 20 Dec 2007 13:30:23 -0000
Subject: [New-bugs-announce] [issue1671] "World" tool ported to py3k
Message-ID: <1198157423.76.0.377708439601.issue1671@psf.upfronthosting.co.za>


New submission from Quentin Gallet-Gilles:

The title says it all.

I also updated the country codes and other TLDs as things have evolved a
bit since 2002.

----------
components: Demos and Tools
files: world_tool.patch
messages: 58874
nosy: quentin.gallet-gilles
severity: normal
status: open
title: "World" tool ported to py3k
versions: Python 3.0
Added file: http://bugs.python.org/file9011/world_tool.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1671>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: world_tool.patch
Type: text/x-patch
Size: 9949 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071220/ba66cf1c/attachment.bin 

From report at bugs.python.org  Thu Dec 20 15:10:24 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 20 Dec 2007 14:10:24 -0000
Subject: [New-bugs-announce] [issue1672] test_subprocess tempfile issue
Message-ID: <1198159824.27.0.376727412433.issue1672@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

Subprocess contains a minor temporary file getter that failed in one of
my terminals due to the method used to obtain a temporary directory
location.

Patch attached.

----------
components: Tests
files: subprocess.patch
messages: 58875
nosy: JosephArmbruster
severity: minor
status: open
title: test_subprocess tempfile issue
versions: Python 3.0
Added file: http://bugs.python.org/file9012/subprocess.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subprocess.patch
Type: text/x-diff
Size: 538 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071220/3f71ae9c/attachment.patch 

From report at bugs.python.org  Thu Dec 20 15:30:53 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Thu, 20 Dec 2007 14:30:53 -0000
Subject: [New-bugs-announce] [issue1673] test_pep277 missing unicode import
Message-ID: <1198161053.25.0.10614183723.issue1673@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

test_pep277 failed on one of my windows boxes.  It looks as if an import
unicode is missing.

See attached patch.

----------
components: Tests
files: testpep277.patch
messages: 58876
nosy: JosephArmbruster
severity: normal
status: open
title: test_pep277 missing unicode import
versions: Python 3.0
Added file: http://bugs.python.org/file9013/testpep277.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testpep277.patch
Type: text/x-diff
Size: 550 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071220/0ec33a19/attachment.patch 

From report at bugs.python.org  Thu Dec 20 17:04:19 2007
From: report at bugs.python.org (Eric Moyer)
Date: Thu, 20 Dec 2007 16:04:19 -0000
Subject: [New-bugs-announce] [issue1674] pythonw.exe crashes when run as
	non-administrator on Windows XP Pro
Message-ID: <1198166659.78.0.580498645891.issue1674@psf.upfronthosting.co.za>


New submission from Eric Moyer:

I installed the python-2.5.1.msi stable package from the python.org
website using a super-user account on my system.  I installed "for all
users" and used the default location and chose to install everything,
not omitting any component.

After installation, I moved the startup menu folder to be a sub-menu of
my Programming startup menu folder.  Then I ran IDLE and typed in a few
recipes from the itertools package to ensure that everything worked. 
Then I logged out and logged back in with my normal user account.  In my
normal account, the three startup menu items "IDLE (Python GUI)",
"Module Docs", and "Python (command line)" all crash.  The first two
crash with a window titled "pythonw.exe - Application Error".  The last
one opens an empty command prompt window before dying with a window
titled "python.exe - Application Error".  All the error windows have the
text, "The application failed to initialize properly (0xc0000022). Click
on OK to terminate the application"

Since it works when I am logged in as an administrator, my guess is that
the error has something to do with windows security.

----------
components: IDLE, Installation, Interpreter Core, Windows
messages: 58896
nosy: Mr.E
severity: major
status: open
title: pythonw.exe crashes when run as non-administrator on Windows XP Pro
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674>
__________________________________

From report at bugs.python.org  Thu Dec 20 20:49:31 2007
From: report at bugs.python.org (Isaac Morland)
Date: Thu, 20 Dec 2007 19:49:31 -0000
Subject: [New-bugs-announce] [issue1675] Race condition in os.makedirs
Message-ID: <1198180171.38.0.482360233935.issue1675@psf.upfronthosting.co.za>


New submission from Isaac Morland:

There appears to be a race condition in os.makedirs.  Suppose two
processes simultaneously try to create two different directories with a
common non-existent ancestor.  For example process 1 tries to create
"a/b" and process 2 tries to create "a/c".  They both check that "a"
does not exist, then both invoke makedirs on "a".  One of these will
throw OSError (due to the underlying EEXIST system error), and this
exception will be propagated.  Note that this happens even though the
two processes are trying to create two different directories and so one
would not expect either to report a problem with the directory already
existing.

----------
messages: 58919
nosy: ijmorlan
severity: minor
status: open
title: Race condition in os.makedirs
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675>
__________________________________

From report at bugs.python.org  Fri Dec 21 02:25:28 2007
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 21 Dec 2007 01:25:28 -0000
Subject: [New-bugs-announce] [issue1676] Fork/exec issues with Tk 8.5/Python
	2.5.1 on OS X
Message-ID: <1198200328.37.0.27301275997.issue1676@psf.upfronthosting.co.za>


New submission from Kevin Walzer:

I've just updated to Tk 8.5 on OS X (Leopard, 10.5.1) and have rebuilt 
Python to link to the new version of Tk. I'm seeing tons of weird error 
messages in my logs when I run IDLE:

12/20/07 8:18:46 PM [0x0-0xa50a5].org.python.IDLE[1300] Break on 
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTION
ALITY___YOU_MUST_EXEC__() to debug. 
12/20/07 8:18:46 PM [0x0-0xa50a5].org.python.IDLE[1300] The process has 
forked and you cannot use this CoreFoundation functionality safely. You 
MUST exec(). 

I'm not sure if this is a showstopper bug or not, but I'm a bit 
concerned about all these error messages. Can someone investigate?

----------
components: Tkinter
messages: 58931
nosy: wordtech
severity: normal
status: open
title: Fork/exec issues with Tk 8.5/Python 2.5.1 on OS X
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676>
__________________________________

From report at bugs.python.org  Fri Dec 21 07:16:13 2007
From: report at bugs.python.org (Isaul Vargas)
Date: Fri, 21 Dec 2007 06:16:13 -0000
Subject: [New-bugs-announce] [issue1677] Ctrl-C will exit out of Python
	interpreter in Windows
Message-ID: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>


New submission from Isaul Vargas:

When running Python 2.5.1 stable in Windows, you can press Ctrl-C as 
many times as you want and it will always output Keyboard Interrupt in 
the interpreter.
Python 3.0a+ will quit if you press ctrl-c too many times. The last 
release of 3.0a2 can handle many interrupts before quitting, but the 
latest snapshot (Dec 20th) can not.

Steps to reproduce:
Run python.exe
hold down ctrl-c, or press it many times. It will quit the interpreter 
eventually.

----------
components: Interpreter Core
messages: 58933
nosy: Dude-X
severity: normal
status: open
title: Ctrl-C will exit out of Python interpreter in Windows
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677>
__________________________________

From report at bugs.python.org  Fri Dec 21 10:38:06 2007
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Fri, 21 Dec 2007 09:38:06 -0000
Subject: [New-bugs-announce] [issue1678] description of startswith is
	confused
Message-ID: <1198229886.41.0.234464815518.issue1678@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi:

In the Library Reference 3.6.1 String Method, the description of
startswith is confused with endswith.  It says:
  prefix can also be a tuple of suffixes to look for.
Here, "suffixes" means "prefixes".

Note: This part is new for 2.5.

----------
components: Documentation
messages: 58937
nosy: mft
severity: normal
status: open
title: description of startswith is confused
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678>
__________________________________

From report at bugs.python.org  Fri Dec 21 13:35:46 2007
From: report at bugs.python.org (Martin Rinehart)
Date: Fri, 21 Dec 2007 12:35:46 -0000
Subject: [New-bugs-announce] [issue1679] tokenizer permits invalid hex
	integer
Message-ID: <1198240546.79.0.598190279926.issue1679@psf.upfronthosting.co.za>


New submission from Martin Rinehart:

The tokenizer accepts '0x' as an integer zero. The documentation says:
   hexinteger ::= 0x|Xhexdigit+

Stumbled on this testing a tokenizer I wrote in Python for another
language. Expected an Error on "int( '0x', 16 )", but didn't get one.

----------
components: Interpreter Core
messages: 58943
nosy: MartinRinehart
severity: normal
status: open
title: tokenizer permits invalid hex integer
type: compile error
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1679>
__________________________________

From report at bugs.python.org  Fri Dec 21 14:43:34 2007
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Fri, 21 Dec 2007 13:43:34 -0000
Subject: [New-bugs-announce] [issue1680] what is
	decimal.Context.get_manager()?
Message-ID: <1198244614.71.0.361237094038.issue1680@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi:

In the section Context Manager Types of the Library reference, the
__enter__ method of context management protocol is explained as:
  An example of a context manager that returns a related object is
  the one returned by decimal.Context.get_manager(). 
But I can't find anything about decimal.Context.get_manager().
Does it mean decimal.localcontext()?

----------
components: Documentation
messages: 58945
nosy: mft
severity: normal
status: open
title: what is decimal.Context.get_manager()?
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1680>
__________________________________

From report at bugs.python.org  Fri Dec 21 17:32:04 2007
From: report at bugs.python.org (Wichert Akkerman)
Date: Fri, 21 Dec 2007 16:32:04 -0000
Subject: [New-bugs-announce] [issue1681] parameter name for optparse
	parse_args incorrect
Message-ID: <1198254724.03.0.257092628104.issue1681@psf.upfronthosting.co.za>


New submission from Wichert Akkerman:

http://www.python.org/doc/2.4.4/lib/optparse-parsing-arguments.html
documents that second named parameter to be 'options'. This is not
correct: the actual name is 'values'.

----------
components: Documentation
messages: 58948
nosy: wichert
severity: normal
status: open
title: parameter name for optparse parse_args incorrect
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1681>
__________________________________

From report at bugs.python.org  Fri Dec 21 18:41:30 2007
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 21 Dec 2007 17:41:30 -0000
Subject: [New-bugs-announce] [issue1682] Move Demo/classes/Rat.py to
	Lib/rational.py and fix it up.
Message-ID: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

This is written against the 3.0 branch, but before submitting it, I need
to backport numbers.py and submit it against 2.6 instead. I'm posting it
now to get a head start on comments.

The numbers.py part is necessary for this to work but will be a separate
patch.

----------
components: Library (Lib)
files: rational.patch
messages: 58949
nosy: jyasskin
severity: normal
status: open
title: Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9021/rational.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rational.patch
Type: application/octet-stream
Size: 33717 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071221/d23dcc5e/attachment-0001.obj 

From report at bugs.python.org  Fri Dec 21 19:53:46 2007
From: report at bugs.python.org (roudkerk)
Date: Fri, 21 Dec 2007 18:53:46 -0000
Subject: [New-bugs-announce] [issue1683] Thread local storage and
	PyGILState_* mucked up by os.fork()
Message-ID: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za>


New submission from roudkerk:

I got a report that one of the tests for processing
(http://cheeseshop.python.org/pypi/processing) was failing with

    Fatal Python error: Invalid thread state for this thread

when run with a debug interpreter.  This appears to be caused by the
interaction between os.fork() and threads.  The following attached
program reliably reproduces the problem for me on Ubuntu edgy for x86.

All that happens is that the parent process starts a subthread then
forks, and then the child process starts a subthread.

With the normal interpreter I get

    started thread -1211028576 in process 18683
    I am thread -1211028576 in process 18683
    started thread -1211028576 in process 18685
    I am thread -1211028576 in process 18685

as expected, but with the debug interpreter I get

    started thread -1210782816 in process 18687
    I am thread -1210782816 in process 18687
    started thread -1210782816 in process 18689
    Fatal Python error: Invalid thread state for this thread
    [5817 refs]

Notice that the child process is reusing a thread id that was 
being used by the parent process at the time of the fork.

The code raising the error seems to be in pystate.c:

    PyThreadState *
    PyThreadState_Swap(PyThreadState *new)
    {
            PyThreadState *old = _PyThreadState_Current;

            _PyThreadState_Current = new;
            /* It should not be possible for more than one thread state
               to be used for a thread.  Check this the best we can in
debug 
               builds.
            */
    #if defined(Py_DEBUG) && defined(WITH_THREAD)
            if (new) {
                    PyThreadState *check = PyGILState_GetThisThreadState();
                    if (check && check != new)
                            Py_FatalError("Invalid thread state for this
thread");
            }
    #endif
            return old;
    }

It looks as though PyGILState_GetThisThreadState() is returning the
thread state of the thread from the parent process which has the same
id as the current thread.  Therefore the check fails.

I think the thread local storage implementation in thread.c should
provide a function _PyThread_ReInitTLS() which PyOS_AfterFork() can
call.  I think _PyThread_ReInitTLS() just needs to remove and free
each "struct key" in the linked list which does not match the id of
the calling thread.

----------
components: Interpreter Core
files: dbg2.py
messages: 58954
nosy: roudkerk
severity: normal
status: open
title: Thread local storage and PyGILState_* mucked up by os.fork()
type: crash
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9023/dbg2.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbg2.py
Type: text/x-python
Size: 517 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071221/6cefb22c/attachment.py 

From report at bugs.python.org  Fri Dec 21 22:57:22 2007
From: report at bugs.python.org (Fazal Majid)
Date: Fri, 21 Dec 2007 21:57:22 -0000
Subject: [New-bugs-announce] [issue1684] CGIHTTPServer does not chdir prior
	to executing the CGI script
Message-ID: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za>


New submission from Fazal Majid:

The CGI specification does not specify the working directory the CGI is
invoked in, but the usual behavior is to use the directory containing
the script.

CGIHTTPServer should either change working directory by default (see
patch below), or offer a hook to be called before the exec() call to the
CGI.


*** /usr/local/lib/python2.4/CGIHTTPServer.py   Tue Apr  4 11:13:23 2006
--- kCGIHTTPServer.py   Fri Dec 21 13:31:40 2007
***************
*** 227,232 ****
--- 227,233 ----
                      pass
                  os.dup2(self.rfile.fileno(), 0)
                  os.dup2(self.wfile.fileno(), 1)
+                 os.chdir(os.path.dirname(scriptfile))
                  os.execve(scriptfile, args, os.environ)
              except:
                  self.server.handle_error(self.request,
self.client_address)

----------
components: Library (Lib)
messages: 58955
nosy: majid
severity: normal
status: open
title: CGIHTTPServer does not chdir prior to executing the CGI script
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1684>
__________________________________

From report at bugs.python.org  Sat Dec 22 06:17:15 2007
From: report at bugs.python.org (PyScripter)
Date: Sat, 22 Dec 2007 05:17:15 -0000
Subject: [New-bugs-announce] [issue1685] linecache .updatecache fails on
	utf8 encoded files
Message-ID: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za>


New submission from PyScripter:

linecache.updatecache works as follows after it finds a module name:

fp = open(fullname, 'rU')
lines = fp.readlines()
fp.close()

It then tries to detect a file encoding comment...

The problem is that readlines fails with a UnicodeDecodeError if the 
file is utf8 encoded, the preferred locale encoding is something else 
and the file contains characters that cannot be decoded.

Instead the function should:
a) read the raw data into a bytes object 
b)then search for a file encoding comment and
c)use one if found else use utf8 since this is not the default file 
encoding.

----------
components: Library (Lib)
messages: 58958
nosy: pyscripter
severity: normal
status: open
title: linecache .updatecache fails on utf8 encoded files
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685>
__________________________________

From report at bugs.python.org  Sat Dec 22 06:21:37 2007
From: report at bugs.python.org (Hagai Gold)
Date: Sat, 22 Dec 2007 05:21:37 -0000
Subject: [New-bugs-announce] [issue1686] string.Template.safe_substitute
	fail when overriding pattern attribute
Message-ID: <1198300897.98.0.955170861548.issue1686@psf.upfronthosting.co.za>


Changes by Hagai Gold:


----------
components: Library (Lib)
files: string.py.diff
nosy: hagaigold
severity: normal
status: open
title: string.Template.safe_substitute fail when overriding  pattern attribute
versions: Python 3.0
Added file: http://bugs.python.org/file9024/string.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1686>
__________________________________

From report at bugs.python.org  Sat Dec 22 18:01:34 2007
From: report at bugs.python.org (lafcadio)
Date: Sat, 22 Dec 2007 17:01:34 -0000
Subject: [New-bugs-announce] [issue1687] plistlib.py restricts <integer> to
	Python int when writing
Message-ID: <1198342894.97.0.416358225944.issue1687@psf.upfronthosting.co.za>


New submission from lafcadio:

In PlistWriter.writeValue() the line 
  "elif isinstance(value, int):"
should be changed to
  "elif isinstance(value, int) or isinstance(value, long):"
since in http://www.apple.com/DTDs/PropertyList-1.0.dtd is no limitation
to signed 32-bit integer.

It occured an error when I tried to write an "iTunes Music Library.xml"
for the line "<key>Play Date</key><integer>3221924209</integer>".

----------
components: Demos and Tools, Macintosh, XML
messages: 58963
nosy: lafcadio
severity: normal
status: open
title: plistlib.py restricts <integer> to Python int when writing
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1687>
__________________________________

From report at bugs.python.org  Sat Dec 22 22:09:33 2007
From: report at bugs.python.org (Vlastimil Brom)
Date: Sat, 22 Dec 2007 21:09:33 -0000
Subject: [New-bugs-announce] [issue1688] Incorrectly displayed non ascii
	characters in prompt using "input()" - Python 3.0a2
Message-ID: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>


New submission from Vlastimil Brom:

While testing the 3.0a2 build (on Win XPh SP2, Czech), I found a 
possible bug in the input() function; 
if the prompt text contains non-ascii characters (even those present in 
the default charset of the system locale - Czech in this case) the 
prompt is displayed incorrectly; however, the inserted value is treated 
as expected.

The print() function deals with these characters correctly. 
This bug occurs in the system console (cmd.exe) only, using idle 
everything works ok.


============ a minimal snapshot of the session follows ==========

Python 3.0a2 (r30a2:59397:59399, Dec  6 2007, 22:34:52) [MSC v.1500 32 
bit (Inte
l)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input("???: ")
??????: 7
'7'
>>> print("???: ")
???:
>>>

==================================


Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit 
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input(u"???: ")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-
2: ordin
al not in range(128)
>>> print u"???: "
???:
>>>

----------
components: Unicode, Windows
messages: 58965
nosy: vbr
severity: normal
status: open
title: Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
__________________________________

From report at bugs.python.org  Sun Dec 23 03:00:34 2007
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 23 Dec 2007 02:00:34 -0000
Subject: [New-bugs-announce] [issue1689] Backport PEP 3141 to 2.6
Message-ID: <1198375234.59.0.21975095893.issue1689@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

This includes r50877 (just the complex_pow part), r56649, r56652,
r56715, r57296, r57302, r57359, r57361, r57372, r57738, r57739, r58017,
r58039, r58040, and r59390.

----------
components: Library (Lib)
files: backport_numbers.patch
messages: 58967
nosy: jyasskin
severity: normal
status: open
title: Backport PEP 3141 to 2.6
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9026/backport_numbers.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1689>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backport_numbers.patch
Type: application/octet-stream
Size: 41995 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071223/878ac81f/attachment-0001.obj 

From report at bugs.python.org  Sun Dec 23 10:44:06 2007
From: report at bugs.python.org (mtvernon)
Date: Sun, 23 Dec 2007 09:44:06 -0000
Subject: [New-bugs-announce] [issue1690] Crash on cancellation of windows
	install
Message-ID: <1198403046.3.0.862581484217.issue1690@psf.upfronthosting.co.za>


New submission from mtvernon:

Steps to reproduce the bug:

1)  Download the "Python 2.5.1 Windows installer (Windows binary -- 
does not include source)".
2)  Select "Install for all users" and click Next.
3)  Click Next.
4)  Click "Advanced".
5)  Click Cancel.
6)  Click "Yes".

----------
components: Installation
messages: 58968
nosy: mtvernon
severity: normal
status: open
title: Crash on cancellation of windows install
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1690>
__________________________________

From report at bugs.python.org  Sun Dec 23 19:48:24 2007
From: report at bugs.python.org (Peter Farson)
Date: Sun, 23 Dec 2007 18:48:24 -0000
Subject: [New-bugs-announce] [issue1691] feature request: methods that
	modify instances should return instance
Message-ID: <1198435704.91.0.997764853339.issue1691@psf.upfronthosting.co.za>


New submission from Peter Farson:

Here's an example:
I'd like to be able to reverse a list for iterating...
for i in range(10).reverse()

This could work if reverse method returned self, but currently it
doesn't return anything.  I think the overhead is slight and worth it.

----------
components: None
messages: 58973
nosy: eukaryot
severity: normal
status: open
title: feature request: methods that modify instances should return instance
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691>
__________________________________

From report at bugs.python.org  Sun Dec 23 22:23:25 2007
From: report at bugs.python.org (Isaul Vargas)
Date: Sun, 23 Dec 2007 21:23:25 -0000
Subject: [New-bugs-announce] [issue1692] Syntax Error exception dosen't
	print string; not informative
Message-ID: <1198445005.3.0.776695836578.issue1692@psf.upfronthosting.co.za>


New submission from Isaul Vargas:

Python 3.0 doesn't print the string with the carat underneath when 
there is a syntax error.

>>> if x
SyntaxError: invalid syntax (<stdin>, line1)
>>> if (x=5):
SyntaxError: invalid syntax (<stdin>, line 1)

Python 2.x behavior:

>>> if (x=5): pass
  File "<stdin>", line 1
    if (x=5): pass

>>> if x
  File "<stdin>", line 1
    if x

----------
messages: 58977
nosy: Dude-X
severity: normal
status: open
title: Syntax Error exception dosen't print string; not informative
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692>
__________________________________

From report at bugs.python.org  Mon Dec 24 09:54:31 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 24 Dec 2007 08:54:31 -0000
Subject: [New-bugs-announce] [issue1693] Please check merge from trunk
Message-ID: <1198486471.23.0.180198879648.issue1693@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Can you please check the merge of typeobject.c from trunk in r59595? I'm
not absolutely sure if it has the desired effect. slot_tp_hash() was
heavily modified in py3k.

----------
assignee: gvanrossum
components: Interpreter Core
keywords: py3k
messages: 58981
nosy: gvanrossum, tiran
priority: normal
severity: normal
status: open
title: Please check merge from trunk
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693>
__________________________________

From report at bugs.python.org  Mon Dec 24 12:53:14 2007
From: report at bugs.python.org (Bernhard Mayr)
Date: Mon, 24 Dec 2007 11:53:14 -0000
Subject: [New-bugs-announce] [issue1694] floating point number round
	failures under Linux
Message-ID: <1198497194.94.0.235082191295.issue1694@psf.upfronthosting.co.za>


New submission from Bernhard Mayr:

[Bernhard at localhost ~]$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f1=0.55
>>> f2=2.25
>>> print '%.1f, %.1f' % (f1, f2)
0.6, 2.2
>>>
 
f1 is rounded to the next higher value, but f2 is not.


C:\>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f1=0.55
>>> f2=2.25
>>> print '%.1f, %.1f' % (f1, f2)
0.6, 2.3
>>>

Under windows it works properly.


If the floating point numbers are encapsulated behind "round(f, 1)" 
both OS show the same output.

----------
components: Interpreter Core
messages: 58983
nosy: falk_steinhauer
severity: major
status: open
title: floating point number round failures under Linux
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1694>
__________________________________

From report at bugs.python.org  Mon Dec 24 18:38:50 2007
From: report at bugs.python.org (tapybugs)
Date: Mon, 24 Dec 2007 17:38:50 -0000
Subject: [New-bugs-announce] [issue1695] time.localtime() docstring has a
	wrong fieldname
Message-ID: <1198517930.52.0.374052241467.issue1695@psf.upfronthosting.co.za>


New submission from tapybugs:

The docstring says "tm_day" but dir() knows "tm_mday" only:

Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> print time.localtime.__doc__
localtime([seconds]) ->
(tm_year,tm_mon,tm_day,tm_hour,tm_min,tm_sec,tm_wday,tm_yday,tm_isdst)

Convert seconds since the Epoch to a time tuple expressing local time.
When 'seconds' is not passed in, convert the current time instead.

>>> print dir(time.localtime())
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__',
'__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__rmul__', '__setattr__', '__str__', 'n_fields',
'n_sequence_fields', 'n_unnamed_fields', 'tm_hour', 'tm_isdst',
'tm_mday', 'tm_min', 'tm_mon', 'tm_sec', 'tm_wday', 'tm_yday', 'tm_year'

----------
components: Documentation
messages: 58985
nosy: tapybugs
severity: minor
status: open
title: time.localtime() docstring has a wrong fieldname
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1695>
__________________________________

From report at bugs.python.org  Tue Dec 25 04:56:15 2007
From: report at bugs.python.org (toxik)
Date: Tue, 25 Dec 2007 03:56:15 -0000
Subject: [New-bugs-announce] [issue1696] Distutils ignore dry-run flag at
	clean-up of distutils.command.build_scripts.copy_scripts
Message-ID: <1198554975.27.0.859114364636.issue1696@psf.upfronthosting.co.za>


New submission from toxik:

It's actually py251.

113             else:
114                 f.close()
115                 self.copy_file(script, outfile)

Earlier, f is set to None if file is not found, and we are in dry-run
mode. Simple solution:

113             elif f:
114                 f.close()
115                 self.copy_file(script, outfile)

----------
components: Distutils
messages: 58988
nosy: ludvig.ericson
severity: normal
status: open
title: Distutils ignore dry-run flag at clean-up of distutils.command.build_scripts.copy_scripts
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696>
__________________________________

From report at bugs.python.org  Tue Dec 25 14:15:01 2007
From: report at bugs.python.org (Pedro Clemente Pereira Neto)
Date: Tue, 25 Dec 2007 13:15:01 -0000
Subject: [New-bugs-announce] [issue1697] Problems with float and "6" type
Message-ID: <1198588501.87.0.184555508194.issue1697@psf.upfronthosting.co.za>


New submission from Pedro Clemente Pereira Neto:

Problems with float and "6" type

Hi, I am having problems both in the Windows version on the Linux
version of Python as put some number with some 6 type that it always
returns a value me, following examples:

>>> 2.0
2.0
>>> 1.55
1.55
>>> 1.56
1.5600000000000001
>>> 1.6
1.6000000000000001
>>> 1.63
1.6299999999999999
>>> 1.64
1.6399999999999999
>>> 1.71
1.71
>>> 6.0
6.0

Recalling that the error happens only with the digit 6 in float.
Thanks for attention.

Pedro Clemente Pereira Neto 
Brasil
pedrocpneto at gmail.com

----------
components: Interpreter Core
messages: 58989
nosy: pedrocpneto
severity: normal
status: open
title: Problems with float and "6" type
type: resource usage
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697>
__________________________________

From report at bugs.python.org  Tue Dec 25 15:22:11 2007
From: report at bugs.python.org (Olivier Croquette)
Date: Tue, 25 Dec 2007 14:22:11 -0000
Subject: [New-bugs-announce] [issue1698] urlparse and usernames containing @
Message-ID: <1198592531.56.0.424360862151.issue1698@psf.upfronthosting.co.za>


New submission from Olivier Croquette:

Some servers allow the @ character is usernames. It gives URLs like:
ftp://user at xyz@host/dir

user at xyz could for example by an email address.

I am not sure if this is RFC compliant. What's sure is that is makes
trouble with urlparse: 


>>> from urlparse import urlparse
>>> p = urlparse("ftp://user at host1@host2/dir") 
>>> print p.username
user
>>> print p.hostname
host1 at host2

By using rsplit instead of split in lib/python2.5/urlparse.py, the
problem can be solved.

----------
components: Library (Lib)
messages: 58990
nosy: ocroquette
severity: normal
status: open
title: urlparse and usernames containing @
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1698>
__________________________________

From report at bugs.python.org  Tue Dec 25 15:34:27 2007
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 25 Dec 2007 14:34:27 -0000
Subject: [New-bugs-announce] [issue1699] unconditional definiton of
	_BSD_SOURCE breaks builds with g++-4.3
Message-ID: <1198593267.05.0.957481308966.issue1699@psf.upfronthosting.co.za>


New submission from Matthias Klose:

as seen in the logs from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455400

both pyconfig.h and png.h define _BSD_SOURCE, which leads to a build
failure with current GCC from the trunk, when both headers are included
by an extension. Either define it only on OpenBSD, or undefine it if it
is already defined (but pyconfig.h.in is autogenerated).

------------------------------------------------------------------------
r56635 | martin.v.loewis | 2007-07-31 21:54:20 +0200 (Tue, 31 Jul 2007)
| 2 lines

Define _BSD_SOURCE, to get access to POSIX extensions on OpenBSD 4.1+.

----------
components: Build
messages: 58991
nosy: doko
severity: normal
status: open
title: unconditional definiton of _BSD_SOURCE breaks builds with g++-4.3
type: compile error
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699>
__________________________________

From report at bugs.python.org  Tue Dec 25 18:08:04 2007
From: report at bugs.python.org (Nguyen Quan Son)
Date: Tue, 25 Dec 2007 17:08:04 -0000
Subject: [New-bugs-announce] [issue1700] Regular Expression inline flags not
	handled correctly for some unicode characters
Message-ID: <1198602484.7.0.730850744576.issue1700@psf.upfronthosting.co.za>


New submission from Nguyen Quan Son:

There is an inconsistency in handling RE inline flags ( e.g. '(?iu)' ) 
when pattern consists of some unicode characters, for example 
characters in range from '\u1ea0' to '\u1ef9'.

Please see code attached for a demonstration of the problem.

----------
components: Regular Expressions
files: re_unicode_flag.py
messages: 58993
nosy: sonnq
severity: normal
status: open
title: Regular Expression inline flags not handled correctly for some unicode characters
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9028/re_unicode_flag.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: re_unicode_flag.py
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071225/23e05258/attachment.txt 

From report at bugs.python.org  Wed Dec 26 18:40:53 2007
From: report at bugs.python.org (hjmjohnson)
Date: Wed, 26 Dec 2007 17:40:53 -0000
Subject: [New-bugs-announce] [issue1701] svn checkout does not work
Message-ID: <1198690853.59.0.588527632506.issue1701@psf.upfronthosting.co.za>


New submission from hjmjohnson:

===========

ping svn.python.org
PING svn.python.org (82.94.237.220): 56 data bytes
64 bytes from 82.94.237.220: icmp_seq=0 ttl=49 time=107.208 ms

========
svn co http://svn.python.org/projects/python/trunk python-svn
svn: PROPFIND request failed on '/projects/python/trunk'
svn: PROPFIND of '/projects/python/trunk': could not connect to server 
(http://svn.python.org)
==========

It appears that the apache access to the svn repository is down.

----------
components: Build
messages: 59003
nosy: hjmjohnson
severity: critical
status: open
title: svn checkout does not work
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1701>
__________________________________

From report at bugs.python.org  Thu Dec 27 05:28:40 2007
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 27 Dec 2007 04:28:40 -0000
Subject: [New-bugs-announce] [issue1702] Word "alias" used in confusing way
	to compare open() and file()
Message-ID: <1198729720.38.0.104417938854.issue1702@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

I was slightly misled by the wording of part of the docs 
(http://docs.python.org/lib/bltin-file-objects.html):
"file() is new in Python 2.2. The older built-in open() is an alias 
for file()."

I actually thought it meant that open was an alias of file, so 
that 'open is file'. However, 
>>> open is file
False

I feel that "alias" is the wrong word to use here, though I don't know 
a suitable replacement.

----------
components: Documentation
messages: 59007
nosy: Devin Jeanpierre
severity: minor
status: open
title: Word "alias" used in confusing way to compare open() and file()
type: rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1702>
__________________________________

From report at bugs.python.org  Fri Dec 28 01:14:34 2007
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 28 Dec 2007 00:14:34 -0000
Subject: [New-bugs-announce] [issue1703] getpass broken in Py3k: must flush()
Message-ID: <1198800874.65.0.655232075234.issue1703@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

getpass (in particular _raw_input, used by unix_getpass and 
default_getpass) prints out a password prompt to a stream (by default 
stdout) but doesn't flush that stream. It assumes calling 
sys.stdin.readline() to read the password causes stdout to be flushed 
(probably a libc file buffering behavior)

This is a problem in Py3k where file buffering is done by Python; 
getpass needs to manually flush the stream it prints the prompt to. 
Otherwise the prompt isn't printed until after the password is entered 
e.g.:

Python 3.0a2 (py3k:59601, Dec 27 2007, 14:28:14) 
[GCC 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import getpass
>>> getpass.getpass()

<no prompt is printed, i type 'foo\n', and only afterwards is the prompt 
printed>

Password: 
'foo'
>>>

Windows doesn't use _raw_input so it wouldn't see this issue.

Attached is a patch to flush the stream. There's no getpass tests so I 
didn't get around to creating one for this issue. Ideally we'd test 
getpass via spawning a python subprocess and ensuring its I/O looked 
correct.

This was noticed on Jython as its file object is now based off Py3k's

----------
components: Library (Lib)
files: getpass_flush-r59601.diff
messages: 59011
nosy: pjenvey
severity: normal
status: open
title: getpass broken in Py3k: must flush()
versions: Python 3.0
Added file: http://bugs.python.org/file9031/getpass_flush-r59601.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1703>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: getpass_flush-r59601.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071228/0670dc4c/attachment.txt 

From report at bugs.python.org  Fri Dec 28 04:58:45 2007
From: report at bugs.python.org (Rich Marinaccio)
Date: Fri, 28 Dec 2007 03:58:45 -0000
Subject: [New-bugs-announce] [issue1704] possible bug in randint
Message-ID: <1198814325.03.0.53847270276.issue1704@psf.upfronthosting.co.za>


New submission from Rich Marinaccio:

I have been using python for Civilization IV map scripting, and I 
believe I have found a small problem with the randint function. Once in 
a blue moon, randint(a,b) returns b + 1, rather than a >= N <= b. I 
have seen this behavior a few times. Here is the code I used to 
determine this.

randIndex = PWRand.randint(0,len(preshuffle)-1)#PWRand calls randint 
directly with these parameters
if randIndex < 0 or randIndex >= len(preshuffle):
    raise ValueError, " bad index shuffling plot list randIndex=%(r)d 
listLength=%(l)d, mapSize=%(s)d" % {"r":randIndex,"l":len
(preshuffle),"s":hm.mapWidth*hm.mapHeight}

#output is
ValueError:  bad index shuffling plot list randIndex=1453 
listLength=1453, mapSize=13824

according to the docs, the max randIndex should be listLength - 1

----------
components: None
messages: 59012
nosy: cephalo
severity: normal
status: open
title: possible bug in randint
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1704>
__________________________________

From report at bugs.python.org  Fri Dec 28 11:47:26 2007
From: report at bugs.python.org (Wummel)
Date: Fri, 28 Dec 2007 10:47:26 -0000
Subject: [New-bugs-announce] [issue1705] trace module does not annotate
	global statement
Message-ID: <1198838846.15.0.754612008579.issue1705@psf.upfronthosting.co.za>


New submission from Wummel:

Hi,

the trace module does not properly count the global statement. So
coverage tests of functions that use the global statement always file.

To reproduce write a simple function using the global statement and
store it in "mytest.py" (which is attached). Then run "python -m trace
-c mytest.py".
You'll see that the global statement line will not be covered (ie. there
is no "1:" at the beginning of the line).

I tested with Python 2.5 and 2.4.

----------
components: Extension Modules
files: mytest.py
messages: 59021
nosy: calvin
severity: normal
status: open
title: trace module does not annotate global statement
type: behavior
Added file: http://bugs.python.org/file9033/mytest.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mytest.py
Type: text/x-python
Size: 155 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071228/63b6dea8/attachment.py 

From report at bugs.python.org  Fri Dec 28 14:22:02 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Dec 2007 13:22:02 -0000
Subject: [New-bugs-announce] [issue1706] Force WINVER 0x0500 (Windows 2000)
Message-ID: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Do you think it's a good idea to force Win2k compatibility by defining
WINVER 0x0500 in PC/pyconfig.h? It fixed the problem with Tcl/Tk, #1601.

http://msdn2.microsoft.com/en-us/library/aa383745.aspx

#define WINVER 0x0500
#define _WIN32_WINNT 0x0500

----------
assignee: loewis
components: Windows
messages: 59022
nosy: loewis, tiran
severity: normal
status: open
title: Force WINVER 0x0500 (Windows 2000)
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Dec 29 05:10:25 2007
From: report at bugs.python.org (Andre Roberge)
Date: Sat, 29 Dec 2007 04:10:25 -0000
Subject: [New-bugs-announce] [issue1707] probable bug in code.py with Python
	3.0a2
Message-ID: <1198901425.7.0.747577606442.issue1707@psf.upfronthosting.co.za>


New submission from Andre Roberge:

There appears to be a bug in code.py in Python 3.0a2/a1.

I believe that the body of
InteractiveConsole().raw_input()
should be changed from

       sys.stdout.write(prompt)
       sys.stdout.flush()
       return sys.stdin.readline()

to
      return input(prompt)

Here's a sample session.

Python 3.0a1 (py3k, Nov 27 2007, 07:40:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import code
>>> console = code.InteractiveConsole()
>>> console.interact()
Python 3.0a1 (py3k, Nov 27 2007, 07:40:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> for i in range(3):
...   print(i)
0
1
2
>>>  # Notice how I could only enter one line inside the loop.
>>>  # Let's try again, with a different definition of raw_input()
>>> import code
>>> console = code.InteractiveConsole()
>>> console.raw_input = input
>>> console.interact()
Python 3.0a1 (py3k, Nov 27 2007, 07:40:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> for i in range(3):
...   print(i)
...
0
1
2
>>>  # Notice how I had to enter an empty line to end the loop - as it
should be.

The same problem affects function definitions - it is impossible to
define a function body with more than one line when running code.interact()

----------
components: Library (Lib)
messages: 59030
nosy: aroberge
severity: normal
status: open
title: probable bug in code.py with Python 3.0a2
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1707>
__________________________________

From report at bugs.python.org  Sun Dec 30 15:18:38 2007
From: report at bugs.python.org (umaxx)
Date: Sun, 30 Dec 2007 14:18:38 -0000
Subject: [New-bugs-announce] [issue1708] improvements for linecache
Message-ID: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>


New submission from umaxx:

here comes a simple patch for linecache core module, which does the
following:

- remove double comment
- instead of adding all lines with readlines() to the cache, just add
seek points for every line
- return lines from cached seek-points instead directly from dict-cache

advantages of this patch:

- reading lines from very big files (>1GB) is no problem anymore
- linecache can handle a large number of large files now 
- updatecache() is faster now because "for line in fp:" is faster than
readlines()

disadvantages:

- reading a single line from cache will be a little bit slower, then
before because of extra open() call to the file

summary:

- this diff presents a different caching approach which is able to
handle a lot of large files too

__future__-work:

- the code is ugly and unstructured, someone needs to beautify it
- an extra function: get_list_of_lines_from_list_of_linenumbers() would
be nice to have
- test-cases for cache-consistence would be nice to have

----------
components: Library (Lib)
files: linecache.py.diff
messages: 59041
nosy: umaxx
severity: minor
status: open
title: improvements for linecache
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9036/linecache.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linecache.py.diff
Type: application/octet-stream
Size: 1888 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071230/461362b8/attachment.obj 

From report at bugs.python.org  Sun Dec 30 15:31:23 2007
From: report at bugs.python.org (umaxx)
Date: Sun, 30 Dec 2007 14:31:23 -0000
Subject: [New-bugs-announce] [issue1709] logging: log actual function name
Message-ID: <1199025083.33.0.488402629269.issue1709@psf.upfronthosting.co.za>


New submission from umaxx:

logging does not have a (formatter) option for logging the actual
function name

Logger class detects function name with findCaller() - *but* does not
pass it to the makeRecord()-call in _log() - why?

would be nice to see this feature implemented, no patch for now :(

----------
components: Library (Lib)
messages: 59042
nosy: umaxx
severity: minor
status: open
title: logging: log actual function name
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1709>
__________________________________

From report at bugs.python.org  Sun Dec 30 17:23:04 2007
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 30 Dec 2007 16:23:04 -0000
Subject: [New-bugs-announce] [issue1710] Pypi's "score" column is not
	explained
Message-ID: <1199031784.56.0.599845472549.issue1710@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

The meaning of the "score" column shown when a search is done on the
pypi database is not clear.
Example:
http://pypi.python.org/pypi?%3Aaction=search&term=http&submit=search

To understand its meaning I had to find this document:
http://pycheesecake.org/#algorithm-for-computing-the-cheesecake-index

IMHO, it would be better putting a note somewhere in the pypi...
something which explains what the "score" value stands for.

----------
messages: 59043
nosy: giampaolo.rodola
severity: normal
status: open
title: Pypi's  "score" column is not explained

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1710>
__________________________________

From report at bugs.python.org  Sun Dec 30 22:30:45 2007
From: report at bugs.python.org (Maarten Thibaut)
Date: Sun, 30 Dec 2007 21:30:45 -0000
Subject: [New-bugs-announce] [issue1711] socket functions that should return
	unsigned int return signed int
Message-ID: <1199050245.75.0.972014457431.issue1711@psf.upfronthosting.co.za>


New submission from Maarten Thibaut:

Socket library functions such as ntohs() return uint16_t, but inside
Python these return values show up as negative numbers. One possible fix
is to convert these return values using pack:

struct.unpack('H', struct.pack('h', ntohs(number)))[0] & 0xffff

----------
components: Library (Lib)
messages: 59047
nosy: mthibaut
severity: normal
status: open
title: socket functions that should return unsigned int return signed int

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711>
__________________________________

From report at bugs.python.org  Sun Dec 30 22:35:14 2007
From: report at bugs.python.org (Ori Avtalion)
Date: Sun, 30 Dec 2007 21:35:14 -0000
Subject: [New-bugs-announce] [issue1712] Small errors in new-style classes
	doc
Message-ID: <1199050514.05.0.343214107383.issue1712@psf.upfronthosting.co.za>


New submission from Ori Avtalion:

These refer to the "New-style and classic classes" section in
Doc/reference/datamodel.rst.

1) The URL should be <http://www.python.org/doc/newstyle/> instead of
<http://www.python.org/doc/newstyle.html>.

2) The last line: "new-style classic old-style"; seems out of place.
Maybe it was once used for indexing, but is pointless now.

----------
components: Documentation
messages: 59048
nosy: salty-horse
severity: minor
status: open
title: Small errors in new-style classes doc
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1712>
__________________________________

From report at bugs.python.org  Mon Dec 31 03:24:02 2007
From: report at bugs.python.org (Carl Drougge)
Date: Mon, 31 Dec 2007 02:24:02 -0000
Subject: [New-bugs-announce] [issue1713] posixpath.ismount() claims symlink
	to .. is mountpoint.
Message-ID: <1199067842.94.0.942613449084.issue1713@psf.upfronthosting.co.za>


Changes by Carl Drougge:


----------
components: Library (Lib)
nosy: drougge
severity: minor
status: open
title: posixpath.ismount() claims symlink to .. is mountpoint.
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1713>
__________________________________

From report at bugs.python.org  Mon Dec 31 16:30:02 2007
From: report at bugs.python.org (Miroslav Suchy)
Date: Mon, 31 Dec 2007 15:30:02 -0000
Subject: [New-bugs-announce] [issue1714] ConfigParser.py do not allow
	leading (and trailing) space in values.
Message-ID: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za>


New submission from Miroslav Suchy:

I have some configuration params with leading space. And program
(getmail4) which use ConfigParser.py. ConfigParser strip all leading
(and trailing) spaces from values. This is very often the most wanted
result. But if I want value with leading space I have no option to put
it there.
Therefore I suggest to optionaly write string value as
key = "value"

This patch will solve it (it is against my OS, sorry no chance to
checkout svn).

--- /usr/lib/python2.4/ConfigParser.py.orig     2007-12-31
16:04:32.000000000 +0100
+++ /usr/lib/python2.4/ConfigParser.py  2007-12-31 16:06:50.000000000 +0100
@@ -472,6 +472,7 @@
                             if pos != -1 and optval[pos-1].isspace():
                                 optval = optval[:pos]
                         optval = optval.strip()
+                        optval = optval.strip('"')
                         # allow empty values
                         if optval == '""':
                             optval = ''

----------
components: Extension Modules
messages: 59060
nosy: msuchy
severity: normal
status: open
title: ConfigParser.py do not allow leading (and trailing) space in values.
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1714>
__________________________________