From report at bugs.python.org  Thu Oct  1 00:14:02 2009
From: report at bugs.python.org (Jan Kratochvil)
Date: Wed, 30 Sep 2009 22:14:02 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254348842.23.0.129918128017.issue7015@psf.upfronthosting.co.za>


Jan Kratochvil <jan.kratochvil at redhat.com> added the comment:

The python bindings were therefore fixed downstream:
gdb-6.8.91.20090930-2.fc12
http://koji.fedoraproject.org/koji/buildinfo?buildID=134595

----------

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

From report at bugs.python.org  Thu Oct  1 00:32:35 2009
From: report at bugs.python.org (Jon Parise)
Date: Wed, 30 Sep 2009 22:32:35 +0000
Subject: [issue7025] Python 3.1 and 3.2 (dev) opensearch.xml still references
	3.0
In-Reply-To: <1254349955.07.0.60985780898.issue7025@psf.upfronthosting.co.za>
Message-ID: <1254349955.07.0.60985780898.issue7025@psf.upfronthosting.co.za>


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

The _static/opensearch.xml output on docs.python.org for the 3.1 and 3.2
(dev/py3k) branches still refers to the 3.0 documentation.

Doc/conf.py's html_use_opensearch value should be updated in those
source branches to reflect their updated version numbers.

----------
assignee: georg.brandl
components: Documentation
messages: 93378
nosy: georg.brandl, jon
severity: normal
status: open
title: Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  1 00:41:27 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Wed, 30 Sep 2009 22:41:27 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254350487.16.0.450989540138.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

A fair point. I was thinking that we could query the OS about whatever
filesystem the path is on, but this wouldn't work for a file that hasn't
been created yet.

The issue with extractall() isn't just that it can extract over existing
files, it's that it can write files anywhere on the filesystem, both by
exploiting symlinks and through path manipulation. The more I think
about it, though, the more I think the case sensitivity is a non-issue
here, since the trailing part of the extraction paths is built out of
the base path, which I then compare against. The capitalization will
therefore be consistent, and I don't need to worry about this. Does this
seem right?

----------

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

From report at bugs.python.org  Thu Oct  1 00:50:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Sep 2009 22:50:50 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254351050.4.0.500781813967.issue6972@psf.upfronthosting.co.za>


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

The patch won't work if the target file already exists as a symlink.

I think that such a check is not a good idea. Using symlinks to extract files 
to somewhere else may be a feature, after all.  Specially if the symlink 
already exists before the operation. Some real-case example:
  /home/xxx/bin   --> symlink to /someotherpath/bin
  /home/xxx/lib   --> symlink to /someotherpath/lib
Now I want to extract "lib/libXXX.so" into "/home/xxx"

I suggest to only update the documentation with a warning, similar to the one 
for the tarfile module.

----------

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

From report at bugs.python.org  Thu Oct  1 01:16:42 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 30 Sep 2009 23:16:42 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254352602.69.0.966276687031.issue6972@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Adding a warning to the documentation is wrong. The intention of the
code clearly is to only create files in the destination directory (or
why remove the first slash then?) and that is also the impression I get
from reading the documentation.

----------

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

From report at bugs.python.org  Thu Oct  1 01:37:05 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 30 Sep 2009 23:37:05 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254353825.44.0.0769477845148.issue6972@psf.upfronthosting.co.za>


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

Adding a warning to the documentation is not wrong, it is the only thing 
that is possible for the 2.6.3 release.  Its too late in the current 
release process to change code.

----------

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

From report at bugs.python.org  Thu Oct  1 02:29:27 2009
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 01 Oct 2009 00:29:27 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1254253653.38.0.148741514276.issue3890@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0909301729t5eda0bfej7493e71c147e215e@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola'
<report at bugs.python.org>wrote:

>
> Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:
>
> Uhm... I'm sorry but actually I'm not sure about this patch anymore.
> Now that I look at ssl.py again I'm noticing that send() is trapped in a
> "while True" loop as well and the patch doesn't cover it.
>
> Not sure if that has been added recently or it was already there at the
> time I submitted the report but it's another thing that need to be
> fixed.
>
>
> Moreover, I'm sure that removing the "while" loop is good for non-
> blocking sockets but what about blocking ones?
> Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised
> in a blocking environment?
>

No.

> If they aren't then the current patch just needs to take care of send()
> method too, then it's fine.
>

Yes, it's fine.

Bill

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola&#39; <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Giampaolo Rodola&#39; &lt;<a href="mailto:billiejoex at users.sourceforge.net">billiejoex at users.sourceforge.net</a>&gt; added the comment:<br>
<br>
Uhm... I&#39;m sorry but actually I&#39;m not sure about this patch anymore.<br>
Now that I look at ssl.py again I&#39;m noticing that send() is trapped in a<br>
&quot;while True&quot; loop as well and the patch doesn&#39;t cover it.<br>
<br>
Not sure if that has been added recently or it was already there at the<br>
time I submitted the report but it&#39;s another thing that need to be<br>
fixed.<br>
<br>
<br>
Moreover, I&#39;m sure that removing the &quot;while&quot; loop is good for non-<br>
blocking sockets but what about blocking ones?<br>
Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised<br>
in a blocking environment?<br></blockquote><div><br>No.<br>??<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If they aren&#39;t then the current patch just needs to take care of send()<br>
method too, then it&#39;s fine.<br></blockquote><div><br>Yes, it&#39;s fine.<br><br>Bill <br></div></div><br>

From report at bugs.python.org  Thu Oct  1 02:49:10 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 00:49:10 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>


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

test test_urllib failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/
test_urllib.py", line 106, in setUp
    env.unset(k)
NameError: global name 'env' is not defined


Looking in trunk's copy I see this:

    def setUp(self):
        # Records changes to env vars
        self.env = test_support.EnvironmentVarGuard()
        # Delete all proxy related env vars
        for k, v in os.environ.iteritems():
            if 'proxy' in k.lower():
                del env[k]

Should not that be "del self.env[k]"?

----------
components: Tests
messages: 93384
nosy: srid
severity: normal
status: open
title: test_urllib: unsetting missing 'env' variable
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  1 02:50:01 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 00:50:01 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254358201.73.0.421656403844.issue7026@psf.upfronthosting.co.za>


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

The above mentioned traceback occurs in 2.6.3rc1

----------

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

From report at bugs.python.org  Thu Oct  1 02:55:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Oct 2009 00:55:22 +0000
Subject: [issue7025] Python 3.1 and 3.2 (dev) opensearch.xml still references
	3.0
In-Reply-To: <1254349955.07.0.60985780898.issue7025@psf.upfronthosting.co.za>
Message-ID: <1254358522.31.0.667258191258.issue7025@psf.upfronthosting.co.za>


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

Fixed in r75161.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 03:01:39 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 01:01:39 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>


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

This test failure occurs on Windows XP (x86) with 2.6.3.rc1

======================================================================
ERROR: Test seek/tell using the StatefulIncrementalDecoder.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python26\lib\test\test_io.py", line 1063, in testSeekAndTell
    testSeekAndTellWithData(input)
  File "C:\Python26\lib\test\test_io.py", line 1043, in
testSeekAndTellWithData
    decoded = f.read()
  File "C:\Python26\lib\io.py", line 1725, in read
    decoder = self._decoder or self._get_decoder()
  File "C:\Python26\lib\io.py", line 1514, in _get_decoder
    decoder = make_decoder(self._errors)
  File "C:\Python26\lib\test\test_io.py", line 636, in __init__
    codecs.IncrementalDecoder.__init__(self, errors)
AttributeError: 'NoneType' object has no attribute 'IncrementalDecoder'

----------
components: Tests
messages: 93387
nosy: srid
severity: normal
status: open
title: test_io.py: codecs.IncrementalDecoder is sometimes None
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct  1 03:20:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2009 01:20:52 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1254360052.63.0.623341552107.issue7027@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, pitrou
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Thu Oct  1 03:51:34 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 01 Oct 2009 01:51:34 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254361894.31.0.169724368198.issue7026@psf.upfronthosting.co.za>


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

Fixed that in revision 75166. Even in release26-maint got to chnage it
from env.unset(k) to self.env.unset(k).

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed

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

From report at bugs.python.org  Thu Oct  1 04:49:52 2009
From: report at bugs.python.org (Tim Lesher)
Date: Thu, 01 Oct 2009 02:49:52 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1254365392.41.0.441819453662.issue3329@psf.upfronthosting.co.za>


Changes by Tim Lesher <tlesher at gmail.com>:


----------
nosy: +tlesher

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

From report at bugs.python.org  Thu Oct  1 04:51:53 2009
From: report at bugs.python.org (Josh Cogliati)
Date: Thu, 01 Oct 2009 02:51:53 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>


New submission from Josh Cogliati <jjcogliati-r1 at yahoo.com>:

The hex() builtin function only takes integers.  Also there is no way to
create a floating point number from a hexadecimal string.  However it
would often be useful to be able to see the hexadecimal version of an
float since this is an exact representation as compared to the decimal
version.  

I propose that the format 0xMantisaP0xBase2Exponent be used (but other
possibilities would be fine.  For example in this way 0.5 decimal would
be 0x1p-0x1 hex.  1.1 decimal would be 0x8cccccccccccdp-0x33 and pi
would be 0x3243f6a8885a3p-0x30

Attached are two functions I created to implement this.  If this would
be better as a PEP I will create one.  

This will cause a slight incompatibility, since now hex will throw an
exception if it is passed a float.

----------
components: Library (Lib)
files: fhex.py
messages: 93389
nosy: jrincayc
severity: normal
status: open
title: hex function should work with floats
versions: Python 3.1
Added file: http://bugs.python.org/file15011/fhex.py

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

From report at bugs.python.org  Thu Oct  1 05:18:53 2009
From: report at bugs.python.org (Josh Cogliati)
Date: Thu, 01 Oct 2009 03:18:53 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254367133.55.0.510961373223.issue7028@psf.upfronthosting.co.za>


Changes by Josh Cogliati <jjcogliati-r1 at yahoo.com>:


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

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

From report at bugs.python.org  Thu Oct  1 07:09:45 2009
From: report at bugs.python.org (fugounashi)
Date: Thu, 01 Oct 2009 05:09:45 +0000
Subject: [issue6733] curses line wrap broken when mixing full- and half-width
	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1254373785.59.0.801627295555.issue6733@psf.upfronthosting.co.za>


Changes by fugounashi <fugounashi+python at gmail.com>:


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

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

From report at bugs.python.org  Thu Oct  1 07:26:27 2009
From: report at bugs.python.org (Harshad Modi)
Date: Thu, 01 Oct 2009 05:26:27 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254374787.05.0.216263392191.issue7024@psf.upfronthosting.co.za>


Harshad Modi <hmo at tinyerp.com> added the comment:

[Senthil Kumaran]
Thanks to Reply.
1) OS : Ubuntu 9.04 - the Jaunty Jackalope - released in April 2009.
2) Default Browser : Firefox 3.0.8
3) Tested with "ftp://ftp.aduni.org" but still error.
4) Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) [GCC 4.3.3] on
linux2

Sorry It is not work for me in python2.6.2 + Ubuntu 9.04 + Firefox 3.0.8

Thanks

----------

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

From report at bugs.python.org  Thu Oct  1 09:33:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Oct 2009 07:33:07 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254382387.87.0.478859980276.issue7028@psf.upfronthosting.co.za>


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

I agree it would be useful.  That's why this facility already exists in 
Python >= 2.6 (including Python 3.x).  :-)

Python 2.6.2 (r262:71600, Jul  8 2009, 09:56:31) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import pi
>>> pi.hex()
'0x1.921fb54442d18p+1'
>>> float.fromhex(_)
3.1415926535897931

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> pending

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

From report at bugs.python.org  Thu Oct  1 09:37:16 2009
From: report at bugs.python.org (Scott Dial)
Date: Thu, 01 Oct 2009 07:37:16 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254382636.77.0.388623235109.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

It would seem the logical patch would be to return the line when the
empty string is returned. This would fall in line with the behavior of
other objects with a readline() in python. In following with that, the
patch I have attached returns a truncated line. Therein, the _get_line()
implementation needs to actually check for the correct termination of
the line (it's arguably a bug as it is, just chucking away the last two
characters blindly).

----------
keywords: +patch
nosy: +scott.dial
Added file: http://bugs.python.org/file15012/imaplib-r75166.patch

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

From report at bugs.python.org  Thu Oct  1 09:41:36 2009
From: report at bugs.python.org (Scott Dial)
Date: Thu, 01 Oct 2009 07:41:36 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254382897.0.0.616904482877.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15012/imaplib-r75166.patch

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

From report at bugs.python.org  Thu Oct  1 09:41:49 2009
From: report at bugs.python.org (Scott Dial)
Date: Thu, 01 Oct 2009 07:41:49 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254382909.58.0.804707616325.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Added file: http://bugs.python.org/file15013/imaplib-r75166.patch

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

From report at bugs.python.org  Thu Oct  1 09:42:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Oct 2009 07:42:51 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254382971.95.0.406968931849.issue7028@psf.upfronthosting.co.za>


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

> I agree it would be useful.  That's why this facility already exists

Ahem.  Embarrassing causation fail.  To clarify, Raymond Hettinger 
proposed this addition some time ago, and others on python-dev supported 
it.  *That's* why it was implemented. :)

----------
status: pending -> open

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

From report at bugs.python.org  Thu Oct  1 09:43:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Oct 2009 07:43:02 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254382982.7.0.417063346456.issue7028@psf.upfronthosting.co.za>


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


----------
status: open -> pending

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

From report at bugs.python.org  Thu Oct  1 09:56:23 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Oct 2009 07:56:23 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254383783.08.0.681518989187.issue7026@psf.upfronthosting.co.za>


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

Can this issue be closed then?

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

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

From report at bugs.python.org  Thu Oct  1 09:57:52 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Oct 2009 07:57:52 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254383872.5.0.672419195926.issue7022@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> pitrou
nosy: +pitrou

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

From report at bugs.python.org  Thu Oct  1 10:58:08 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 01 Oct 2009 08:58:08 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254387488.81.0.815833059741.issue7026@psf.upfronthosting.co.za>


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

This needs to be changed in python2.6 branch as well. I was hesitant as
barry was making the build. After the branch opens, I shall make the
changes in that and close the issue.

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

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

From report at bugs.python.org  Thu Oct  1 12:11:13 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 01 Oct 2009 10:11:13 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254391873.01.0.230283572009.issue6972@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I'd rather have an extractall version which just throws a RuntimeError
than one which overwrites any file with any content on my filesystem if
I'm trying to unzip a zip file.  Then I at least know that I have to
write my own version. Adding a warning to the documentation instead of
fixing that bug was wrong for the tarfile module and is wrong for the
zipfile module. The "release process" disagrees with me here, but I'd
still call that wrong.

----------

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

From report at bugs.python.org  Thu Oct  1 12:34:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 10:34:59 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1254393299.23.0.502437415422.issue7027@psf.upfronthosting.co.za>


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

This is something that sometimes happens when running the test suite due
to module initialization or finalization oddities (I don't understand
the precise reasons myself). It isn't specific to test_io, I think.

----------
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  1 12:55:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 10:55:09 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254394509.49.0.994721266868.issue7022@psf.upfronthosting.co.za>


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

If you are requesting new `start` and `end` arguments to readinto(), the
way to do that today is to use a memoryview:

   # b is your bytearray, f your IO object
   m = memoryview(b)[start:end]
   f.readinto(m)

If you still want that feature, please open a separate bug (doc updates
and feature requests should be open separately) :-)

As for the first part of the report (RawIOBase.read), I'll look into it.

----------

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

From report at bugs.python.org  Thu Oct  1 12:58:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 10:58:52 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254394732.18.0.245715744272.issue7022@psf.upfronthosting.co.za>


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

Actually, I'm not sure what is wrong with the current doc:

read(n=-1)?
    Read and return up to n bytes from the stream. As a convenience, if
n is unspecified or -1, readall() is called. Otherwise, only one system
call is ever made. An empty bytes object is returned on EOF; None is
returned if the object is set not to block and has no data to read.

(http://docs.python.org/dev/py3k/library/io.html)

----------

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

From report at bugs.python.org  Thu Oct  1 12:59:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 10:59:10 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254394750.47.0.622921768544.issue7022@psf.upfronthosting.co.za>


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


----------
priority:  -> normal
type: feature request -> behavior
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Oct  1 13:01:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 11:01:40 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254394900.82.0.053229549415.issue7028@psf.upfronthosting.co.za>


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


----------
status: pending -> closed

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

From report at bugs.python.org  Thu Oct  1 13:02:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 11:02:33 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254394953.78.0.251971605627.issue3890@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15010/unnamed

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

From report at bugs.python.org  Thu Oct  1 13:06:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 11:06:43 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1254395203.1.0.233584526116.issue1759169@psf.upfronthosting.co.za>


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

We're in the middle of a release so this will have to wait until we are
done.
Apart from that, is there a reason *not* to apply the patch?
(it only seems to affect Solaris after all, and Solaris users here seem
consensual that the patch should be applied)

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

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

From report at bugs.python.org  Thu Oct  1 13:07:22 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Oct 2009 11:07:22 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254395242.0.0.690420192403.issue5949@psf.upfronthosting.co.za>


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

Probably too late for 2.6.3 - assigning to Barry to check anyway.

----------
assignee:  -> barry
nosy: +barry, ncoghlan

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

From report at bugs.python.org  Thu Oct  1 14:20:30 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 01 Oct 2009 12:20:30 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254399630.02.0.0303000525493.issue5949@psf.upfronthosting.co.za>


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

I'm afraid so.  Please consider this for landing after 2.6.3 is released.

----------
assignee: barry -> 

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

From report at bugs.python.org  Thu Oct  1 14:24:49 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 01 Oct 2009 12:24:49 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1254399889.56.0.941112643427.issue2986@psf.upfronthosting.co.za>


Changes by Geoffrey Bache <gjb1002 at users.sourceforge.net>:


----------
nosy: +gjb1002

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

From report at bugs.python.org  Thu Oct  1 14:29:21 2009
From: report at bugs.python.org (Josh Cogliati)
Date: Thu, 01 Oct 2009 12:29:21 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254400161.0.0.0448404178183.issue7028@psf.upfronthosting.co.za>


Josh Cogliati <jjcogliati-r1 at yahoo.com> added the comment:

Thank you for telling me about that function.  I read the documentation
on hex() and never realized that there was a second instance method
float.hex().  

I am curious why the proper way to turn a number into hex is the following:
import types

def to_hex(a):
    if type(a) == type(0.0):
        return a.hex()
    elif type(a) == type(1):
        return hex(a)
    else:
        raise TypeError('Must be int or float')



As in why does neither int.hex() or hex(float) work?

Thank you.

----------

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

From report at bugs.python.org  Thu Oct  1 14:47:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Oct 2009 12:47:47 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254401267.17.0.604540685023.issue7028@psf.upfronthosting.co.za>


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

Josh, see the issue 3008 discussion.

----------

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

From report at bugs.python.org  Thu Oct  1 14:49:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Oct 2009 12:49:01 +0000
Subject: [issue6733] curses line wrap broken when mixing full- and half-width
	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1254401341.84.0.105723249381.issue6733@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Thu Oct  1 15:44:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 13:44:33 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254404673.78.0.159133221617.issue1625@psf.upfronthosting.co.za>


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

Some notes about posting patches:
- you should post the patch alone, not in an archive
- generally you should post patches against the 2.7 trunk, we take care
of merging them to py3k ourselves (but in this case the difference
should be minimal anyway)
- I'm not sure it's ok to add legal boilerplate at the top of files, we
never do that usually (and if everyone did it would become unreadable).
Does your company require you to do so?

I'll look at the patch itself another day, I don't have the time right
now. But thanks for posting it!

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

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

From report at bugs.python.org  Thu Oct  1 16:21:43 2009
From: report at bugs.python.org (David Bonner)
Date: Thu, 01 Oct 2009 14:21:43 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254406903.53.0.479184342261.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

Thanks for the reply.

My company's legal dept. told me that we needed to put the boilerplate
into the files as part of releasing it under the apache license.  I used
a tarball because they also recommended including a full copy of the
license with the patch.

I'm reattaching just the patch to the bug now.  I'll check with legal
and see if they'd have a problem with removing the boilerplate.

----------
keywords: +patch
Added file: http://bugs.python.org/file15014/py3k_bz2.patch

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

From report at bugs.python.org  Thu Oct  1 16:29:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2009 14:29:44 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254407384.74.0.464000177408.issue1625@psf.upfronthosting.co.za>


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

If the patch is substantial enough that legal boilerplate is even an
issue, then I'm pretty sure a contributor agreement will be required for
patch acceptance, at which point I think the boilerplate won't be
needed.  The Apache license is certainly acceptable.  I'm obviously not
the authority on this, though.  That would be van Lindburg.

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

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

From report at bugs.python.org  Thu Oct  1 17:22:51 2009
From: report at bugs.python.org (Dariusz Suchojad)
Date: Thu, 01 Oct 2009 15:22:51 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254410571.68.0.69424867265.issue6992@psf.upfronthosting.co.za>


Dariusz Suchojad <dsuch at users.sourceforge.net> added the comment:

Hello,

funny the bug report should surface in the very same time I was looking
for a way to put 2 authors in the 'author' field :-)

[Antoine Pitrou (pitrou)]
> It is still unknown what use case the new "author" scheme would solve 
> that the old one doesn't

I believe I have such a use case. I'm in the middle of taking over a
Python package and I would like to give credits to the original author
who passed the development over to me. You see, *he is* the author of
95% of the code, it seems unfair to replace his name with my own. I
thought I could simply use a list of authors but the 'author' field
hasn't been designed for it.

[Antoine Pitrou (pitrou)]
> (does someone want the "author"field to be machine parsable?
> for what purpose?),

I'm just a regular user and when I see a field described as a 'meta' one
then I'm actually not wondering how any future tools will take 
advantage of it. It being a 'meta' I understand it's mostly meant to be
interpreted by machines which, funnily enough, seems to be just to the
contrary of what you say.

Of course one can put anything they wish into 'author', it could even 
be CSV or XML but that's not the point, the point is that some things
simply have two and more authors and inserting the mailing list isn't
exactly the same. Sure, I can simply put it all in an AUTHORS file but
again it's not the same, what would be the 'author' field for then?

If someone were to ask me then I'd say there should only be the 'author'
and 'contributor' fields which both have a clear meaning in open-source
world, accepting both a string and a list/tuple in format of 'Foo Bar
<foobar at example.com>' which makes for easy parsing and other fields
discussed here should be deprecated. No one likes type checking but at
least it would provide backwards-compat for the most widely used field.
Just my 2c.

author = 'Foo Bar <foobar at example.com>'
author = ['Foo Bar <foobar at example.com>', 'Baz Frobble
<bazfrobble at example.com>']

But hey, I still very much like distutils :-) and I understand all the 
backwards-compatibility concerns, but as a user I can clearly see a need
for /some/ way to specify more than one author without having to wonder
what will any not-yet-written tool do with this or any other meta field.

----------
nosy: +dsuch

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

From report at bugs.python.org  Thu Oct  1 17:59:11 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 01 Oct 2009 15:59:11 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254412751.05.0.876886173847.issue7022@psf.upfronthosting.co.za>


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

Thanks for the memoryview tip - I though I was up-to-date with python's
features but obviously I wans't ^^ (I searched through dict views but
that wasn't it...)
It should be exactly what's needed to replace these unnecessary
additional arguments.

As for the simple doc update, I was just pointing out the fact that EOF
is reached if read methods returns an empty bytes AND we didn't ask for
0 bytes. Just to avoid confusing people : file.read(0) will always
return an empty bytes, but it doesnt mean that we're at eof, contarrily
to what the doc currently says B-)

----------

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

From report at bugs.python.org  Thu Oct  1 18:19:24 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Thu, 01 Oct 2009 16:19:24 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254242385.27.0.666380819372.issue7019@psf.upfronthosting.co.za>
Message-ID: <4AC4D682.8040108@gmx.de>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

[...]
> How did you encounter this in the first place?

I was working on PyPy's marshaler, broke it in such a way that it was 
producing the bad input that I gave above. Then I fixed it, but didn't 
kill my .pyc files. So a few days later I got a long zero with the 
properties above in PyPy (which was quite annoying to debug). Then I 
figured that CPython likely has the same problem.

Thanks a lot for fixing this!

Carl Friedrich

----------

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

From report at bugs.python.org  Thu Oct  1 18:28:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Oct 2009 16:28:06 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254414486.23.0.745800041455.issue7022@psf.upfronthosting.co.za>


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

Ok, I've improved the docs a bit in r75168. Thanks!

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

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

From report at bugs.python.org  Thu Oct  1 18:43:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 16:43:25 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254415405.74.0.734694189085.issue7020@psf.upfronthosting.co.za>


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

Apparently Zope2 build fails for the same reason on 2.6.3rc1 (I'm 
attaching the log file)

  File "c:\python26\lib\distutils\command\build_ext.py", line 633, in 
get_ext_fullpath

    filename = self.get_ext_filename(modpath[-1])

  File "c:\python26\lib\site-packages\setuptools-0.6c9-py2.6.egg
\setuptools\command\build_ext.py", line 85, in get_ext_filename

KeyError: 'cAccessControl'

----------
Added file: http://bugs.python.org/file15015/zop2-build-failure.txt

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

From report at bugs.python.org  Thu Oct  1 18:53:38 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 01 Oct 2009 16:53:38 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254416018.44.0.0431690593208.issue7020@psf.upfronthosting.co.za>


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

Its a setuptools bug.

That's because it uses Setuptools, which patches Distutils behavior, as
soon as you "import setuptools".

Matthias Klose and I have fixed this flaw in debian, and it is also
fixed in Distribute, but not in Setuptools.

----------

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

From report at bugs.python.org  Thu Oct  1 19:03:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 01 Oct 2009 17:03:50 +0000
Subject: [issue7020] regression in pywin32 build due to 2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254416630.5.0.708468260903.issue7020@psf.upfronthosting.co.za>


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

Tarek was referring to this bug - http://bitbucket.org/tarek/distribute/
issue/41/ - above.

----------

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

From report at bugs.python.org  Thu Oct  1 19:16:44 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 01 Oct 2009 17:16:44 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The attached patch contains suggested fixes to pybench.py:
1) add a processtime timer for windows
2) fix a bug in timer selection: timer wasn't put in 'self'
3) Collect 'gross' times for each round
4) show statistics for per-round sums, both for sum of "adjusted" times 
for each round, and 'gross' time per round.

The last one is important.  Traditionally, the focus would be on 
individual tests.  The series of individual timings for each test would 
be  examined, min and afverage found.  These minima and averages would 
then be summed up to get a total time.  These results are very noisy.  
In addition, the sum of individual minima is not a linear operator that 
has any meaning and is thus extremely noisy.

Looking at the minimum and average of the sum is a much stabler 
indication of total benchmark performance.

Another thing that I found when working with this, is that using 
"calibration" significantly adds to noise and can produce incorrect 
results.  It adds a level of non-linearity to the results that can 
appear very strange.  Typically the 'overhead' is so low that we should 
consider skipping the calibration.  The purpose of the benchmark must be 
to measure the performance of python in context.  The meaning of 
individual operations in isolation are pretty meaningless.  Although I 
didn't change the default number of calibration runs from 10, I would 
suggest documenting that it may be useful to turn it to 0 to increase 
predictability and get numbers indicative of real performance.

----------
components: Demos and Tools
files: pybench.patch
keywords: patch
messages: 93416
nosy: krisvale
severity: normal
status: open
title: Improve pybench
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15016/pybench.patch

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

From report at bugs.python.org  Thu Oct  1 20:12:47 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Oct 2009 18:12:47 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <4AC4F118.4050304@egenix.com>


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

Kristj?n Valur J?nsson wrote:
>

Thanks for the patch. Here's a quick review (a bit terse, but
hope you don't mind)...

> The attached patch contains suggested fixes to pybench.py:
> 1) add a processtime timer for windows

I'm not sure why you added this: the systimes.py module
already has a ctypes wrapper for kernel32.GetProcessTimes() ?!

All you have to do is use this command line option to
enable it: --timer systimes.processtime

> 2) fix a bug in timer selection: timer wasn't put in 'self'

Thanks for spotting this one.

> 3) Collect 'gross' times for each round

I'm assuming that "gross" = test time + overhead. Is that right ?

I like the idea, but not the implementation :-) Don't like my own
pybench statistics implementation much either. I plan to
rewrite it for Python 2.7.

> 4) show statistics for per-round sums, both for sum of "adjusted" times 
> for each round, and 'gross' time per round.
> 
> The last one is important.  Traditionally, the focus would be on 
> individual tests.  The series of individual timings for each test would 
> be  examined, min and afverage found.  These minima and averages would 
> then be summed up to get a total time.  These results are very noisy.  
> In addition, the sum of individual minima is not a linear operator that 
> has any meaning and is thus extremely noisy.
> 
> Looking at the minimum and average of the sum is a much stabler 
> indication of total benchmark performance.

I agree. For the minimum times, the minimum over all tests
should be used.

> Another thing that I found when working with this, is that using 
> "calibration" significantly adds to noise and can produce incorrect 
> results.  It adds a level of non-linearity to the results that can 
> appear very strange.  Typically the 'overhead' is so low that we should 
> consider skipping the calibration.  The purpose of the benchmark must be 
> to measure the performance of python in context.  The meaning of 
> individual operations in isolation are pretty meaningless.  Although I 
> didn't change the default number of calibration runs from 10, I would 
> suggest documenting that it may be useful to turn it to 0 to increase 
> predictability and get numbers indicative of real performance.

The idea behind the calibration is to hide away the overhead
of setting up the test. You're right, that nowadays the tests
run so fast, that the calibration causes more noise than do
good.

This is due to the fact that the number of iteration rounds
and test "packs" were chosen in 2006. Back then, both Python
and the CPUs were a lot slower.

OTOH, timers have not gotten a lot more accurate.

As a result, the measurements of pybench on todays machines
have far more noise than they did in 2006.

The only way to resolve this is to adjust all tests - something
which I also plan to do in time for Python 2.7.

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

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

From report at bugs.python.org  Thu Oct  1 20:35:03 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 01 Oct 2009 18:35:03 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1254422103.69.0.733083377632.issue6958@psf.upfronthosting.co.za>


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

I retract this request.  It seems the idea is not liked or a solution is
not easy.

(The solution I now use is to start Python from a batch file that parses
some command line flags itself, sets environment variables, and my
sitecustomize.py file configures logging).

Thanks for the comments.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 22:09:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Oct 2009 20:09:01 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>


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

The py3k unittest docs have a few instances of:

  .. versionadded:: 2.7

and

  .. versionchanged:: 2.7

Presumably all of these should be either 3.1 or 3.2.  I'd fix them, but 
I think Michael has a much better chance of getting all the version 
numbers right. :)

----------
assignee: michael.foord
components: Documentation
messages: 93419
nosy: mark.dickinson, michael.foord
severity: normal
status: open
title: Update version{added,changed} entries in py3k unittest docs
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  1 22:13:22 2009
From: report at bugs.python.org (Thomas W. Barr)
Date: Thu, 01 Oct 2009 20:13:22 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254428002.97.0.400284149237.issue6972@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

Even if we can't fix things for this release, presumably it's not too
late to fix things for 2.7, right?

Yes, there certainly are cases where you might want to have creative
usage of symlinks and stored paths to allow overwriting existing files,
and placing files outside of the extraction path, but that doesn't seem
like the default case to me. Would it be a decent compromise to add a
extract_under_path=True default option to extract() and extractall() for
2.7?

----------

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

From report at bugs.python.org  Thu Oct  1 22:22:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Oct 2009 20:22:31 +0000
Subject: [issue7031] add assertIsInstance
Message-ID: <1254428551.17.0.819786808833.issue7031@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: michael.foord
components: Library (Lib)
files: assertIsInstance.diff
keywords: easy, needs review, patch, patch
nosy: georg.brandl, michael.foord
priority: normal
severity: normal
status: open
title: add assertIsInstance
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15017/assertIsInstance.diff

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

From report at bugs.python.org  Thu Oct  1 22:38:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Oct 2009 20:38:41 +0000
Subject: [issue7031] add assertIsInstance
In-Reply-To: <1254429521.52.0.503933767449.issue7031@psf.upfronthosting.co.za>
Message-ID: <1254429521.52.0.503933767449.issue7031@psf.upfronthosting.co.za>


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

Change negated method name to assertNotIsInstance.

----------
Added file: http://bugs.python.org/file15018/assertIsInstance2.diff

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

From report at bugs.python.org  Thu Oct  1 22:53:41 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 01 Oct 2009 20:53:41 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1254430421.58.0.875698714559.issue7029@psf.upfronthosting.co.za>


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

Hello Marc-Andre.
1) yes, this is nonsense.  I thought that "systimes" was some archaeic 
module that had been discontinued, since I didn't find it in the 
standard modules (where "time" is).  I didn't realize that it was a 
special helper sibling-module to pybench.

3) 'gross', yes, as opposed to 'net'.  The total time of each round.  
For timers which don't update frequently, such as GetProcessTimes(), 
summing up many small contributions compounds the error (in this case, 
+- 10ms per measurement).  Can you be more specific about what it is 
that you don't like?

About the calibration:  I ran into problems where I was tuning the 
memory allocator.  I put HeapAlloc in place of malloc() and found a 
consistent 10% performance degradation, even when using the LFH.  I was 
puzzled by this until I turned off calibration and the effect went away.

The calibration technique is not a bad idea, but it would be helpful, 
when one is comparing runs, to be able to keep the calibration times of 
the previous run, so as not to introduce a random element into the 
comparison.  Alternatively, explain that when doing successive tests, 
the lowest variance in the result is to be expeced with -C 0.

So, how can I improve this?

----------

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

From report at bugs.python.org  Thu Oct  1 22:59:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Oct 2009 20:59:43 +0000
Subject: [issue7031] add assertIsInstance
In-Reply-To: <1254429521.52.0.503933767449.issue7031@psf.upfronthosting.co.za>
Message-ID: <1254430783.77.0.795183634928.issue7031@psf.upfronthosting.co.za>


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

Committed in r75180.

----------
assignee: michael.foord -> georg.brandl
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 00:29:45 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 01 Oct 2009 22:29:45 +0000
Subject: [issue7032] Make assertMultilineEqual default for unicode string
	comparison in
In-Reply-To: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
Message-ID: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>


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

unittest.TestCase.assertEqual uses the new type equality functions for
comparing containers. 

In Python 2.7 assertMultilineEqual should be the default comparison
method for unicode strings and in Python 3.2 for comparing strings.

assertMultilineEqual should only use difflib for showing differences for
strings above a certain length. (For short strings the extra output is
actually more confusing than helpful.)

----------
assignee: michael.foord
messages: 93424
nosy: michael.foord
severity: normal
status: open
title: Make assertMultilineEqual default for unicode string comparison in
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Oct  2 00:46:18 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 01 Oct 2009 22:46:18 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1254437178.64.0.695140576397.issue6958@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Ok. I think it's a reasonable request, but I can see that implementing
it naively without some further thought will lead to (justifiable)
complaints from some users that the behaviour is contradictory or
unintuitive in terms of which configuration "wins" in the event of
ambiguity.

----------

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

From report at bugs.python.org  Fri Oct  2 02:55:34 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 02 Oct 2009 00:55:34 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254444934.23.0.0146053654228.issue6972@psf.upfronthosting.co.za>


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

yes this will be fixed in 2.7/3.2.

as for creative uses where someone might want the out of supplied path 
overwriting behavior?  those people are insane and should be made to jump 
through extra hoops to get it. ;)

----------

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

From report at bugs.python.org  Fri Oct  2 02:55:44 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 02 Oct 2009 00:55:44 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1254444944.41.0.717939759073.issue6972@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Oct  2 04:43:26 2009
From: report at bugs.python.org (Josh Cogliati)
Date: Fri, 02 Oct 2009 02:43:26 +0000
Subject: [issue7028] hex function should work with floats
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254451406.63.0.483803183442.issue7028@psf.upfronthosting.co.za>


Josh Cogliati <jjcogliati-r1 at yahoo.com> added the comment:

Okay.  Thank you. I looked at the issue 3008 discussion.  I see why
hex() was not changed.  Can int.hex() and int.fromhex() be added for
symmetry?  I am willing to work on the patch, it just might be a bit. 
As well, either way, it might be useful for the documentation for hex()
to mention float.hex().  

Thanks.

----------

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

From report at bugs.python.org  Fri Oct  2 10:47:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Oct 2009 08:47:13 +0000
Subject: [issue7028] Add int.hex for symmetry with float.hex
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254473233.87.0.279427364398.issue7028@psf.upfronthosting.co.za>


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

> Can int.hex() and int.fromhex() be added for symmetry?

On the face of it, adding int.hex (and presumably also long.hex for 2.x)
seems reasonable:  in general, integers should be acceptable where-ever
floats are, and by that argument x.hex() should work regardless of
whether x is an integer or a float.

However, I'm opposed to adding int.hex, for a few reasons:

  - the problem that float.hex solves is special to floats, namely that
    the usual representation of a float (via repr) doesn't show the
    *exact* value of that float clearly.  This isn't a problem for
    integers, Fractions, Decimals, etc.

  - there's no danger of silent errors here:  x.hex() will raise an
    exception if x is an integer, giving the programmer an opportunity
    to correct this to e.g.  'float(x).hex()', or perhaps
    'x.hex() if isinstance(x, float) else hex(x)'.  But which one?
    Which leads me to:

  - it's not clear what the output of n.hex() would be:  e.g., should
    (3).hex() match (3.0).hex(), or hex(3)?  Or should it be something
    else again? I'd suggest that different use-cases would need
    different choices here.

  - TSBO---APOO---OWTDI  (see 'import this')

  - I just don't see a real usecase for int.hex.  float.hex is a
    little-used but nice-to-have convenience function.  When it's
    used, it's almost certainly being used on a float.  Feel free
    to give examples of code that would benefit from int.hex.

The case for adding int.fromhex is even weaker: float.fromhex is a class
method, and will usually be called in the form
'float.fromhex(mystring)'.  If you already know you want a hex_string to
int conversion, what's wrong with int(my_string, 16)?

In short, PBP (see 'import this' again).

If you really care about this, you could take the discussion to the
python-ideas mailing list and try to persuade people there; if everyone
feels that int.hex() *should* be added then I'll happily eat my words
and agree to add it.

Raymond, care to offer a second opinion?

----------
components: +Interpreter Core -Library (Lib)
nosy: +rhettinger
resolution: out of date -> 
status: closed -> open
title: hex function should work with floats -> Add int.hex for symmetry with float.hex
versions: +Python 2.7, Python 3.2 -Python 3.1

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

From report at bugs.python.org  Fri Oct  2 11:04:11 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Fri, 02 Oct 2009 09:04:11 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1254474251.38.0.918025913985.issue5097@psf.upfronthosting.co.za>


Kandalintsev Alexandre <bug_hunter at messir.net> added the comment:

Please don't keep this bug open :(

----------

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

From report at bugs.python.org  Fri Oct  2 11:14:23 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Oct 2009 09:14:23 +0000
Subject: [issue7028] Add int.hex for symmetry with float.hex
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254474863.08.0.696399172902.issue7028@psf.upfronthosting.co.za>


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

[Josh]
> As in why does neither int.hex() or hex(float) work?

I believe the answer to this is that Guido wanted hex() to be a purely
integer concept.  This was part of a broader effort relating to the
__index__ magic method.  The intent of that method is to be able to
designate functions or methods as taking only integer arguments and
flagging float arguments as errors.  Indexing was a typical example
where arr[3.1] would have gotten coerced to arr[3], possibly hiding an
error in logic.

The current situation represents a trade-off between parallel/consistent
APIs across numeric types versus catching errors for integral functions
that are erroneously fed a real valued argument.

While I personally wished for the consistent API (i.e. hex() supporting
ints and floats), in reality, I've found no real-world use cases where I
needed to map a hexlifying function to mixed input containing both ints
and floats.  That suggests that the use cases are orthogonal and nothing
was really lost by having two different APIs.

----------

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

From report at bugs.python.org  Fri Oct  2 11:44:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 02 Oct 2009 09:44:29 +0000
Subject: [issue5500] tarfile: path problem in arcname under windows
In-Reply-To: <1237304162.51.0.555320282686.issue5500@psf.upfronthosting.co.za>
Message-ID: <1254476669.2.0.290861144911.issue5500@psf.upfronthosting.co.za>


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

> The archive is created, and the path in the archive is 
> 'C:\\testtarfile\\testtarfile.py', not 'test/testtarfile.py' 
> as I would expect.

I don't see the path you mention. Which archive manager do you use?
I tried with 7-zip, and it shows that I can browse to a path named
C:\testtarfile\tarfiletst.tar.gz\C:\testtarfile\tarfiletst.tar\test\
which contains testtarfile.py.

C:\testtarfile\tarfiletst.tar.gz contains
"C:\testtarfile\tarfiletst.tar", which itselfs contains
"test\testtarfile.py"

IOW, 7-zip simply fails to understand the .tar.gz format as a single
compressed archive.
To extract it properly, it's easy enough to browse the content until you
open the content of the .tar.

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

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

From report at bugs.python.org  Fri Oct  2 12:04:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Oct 2009 10:04:56 +0000
Subject: [issue7032] Make assertMultilineEqual default for unicode string
	comparison in
In-Reply-To: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
Message-ID: <1254477896.69.0.832249461459.issue7032@psf.upfronthosting.co.za>


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

Why only unicode strings?

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

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

From report at bugs.python.org  Fri Oct  2 12:12:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Oct 2009 10:12:18 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254478338.51.0.289002090323.issue7024@psf.upfronthosting.co.za>


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

No problem here, with Firefox 3.0.13 and Python 2.6.3.

----------
assignee:  -> georg.brandl
nosy: +georg.brandl, pitrou

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

From report at bugs.python.org  Fri Oct  2 12:14:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Oct 2009 10:14:33 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254478473.27.0.177576659415.issue7024@psf.upfronthosting.co.za>


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

If you are under GNOME, you might fire gconf-editor and check the value
of the keys in /desktop/gnome/url-handlers/ftp.

----------

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

From report at bugs.python.org  Fri Oct  2 12:15:35 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Oct 2009 10:15:35 +0000
Subject: [issue7032] Make assertMultilineEqual default for unicode string
	comparison in
In-Reply-To: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
Message-ID: <1254478535.3.0.366653458549.issue7032@psf.upfronthosting.co.za>


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

Because diffing binary data isn't useful...

This is the reason that assertMultilineEqual isn't already the default
for comparing strings - because in Python 2 when you have strings you
don't know if the intention is for them to contain textual information
or binary information.

----------

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

From report at bugs.python.org  Fri Oct  2 12:41:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Oct 2009 10:41:30 +0000
Subject: [issue7032] Make assertMultilineEqual default for unicode string
	comparison in
In-Reply-To: <1254478535.3.0.366653458549.issue7032@psf.upfronthosting.co.za>
Message-ID: <1254479843.5457.14.camel@localhost>


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

> Because diffing binary data isn't useful...

But often it's non-binary data ;)

> This is the reason that assertMultilineEqual isn't already the default
> for comparing strings - because in Python 2 when you have strings you
> don't know if the intention is for them to contain textual information
> or binary information.

You could have a heuristic which counts the number of "\n" bytes and, if
there are more than 1/80th of them, you're likely to have some text.

(80 being the typical max line length)

----------

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

From report at bugs.python.org  Fri Oct  2 12:58:18 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Oct 2009 10:58:18 +0000
Subject: [issue7032] Make assertMultilineEqual default for unicode string
	comparison in
In-Reply-To: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
Message-ID: <1254481098.84.0.367432259367.issue7032@psf.upfronthosting.co.za>


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

Heh - all ascii would be a better heuristic, or zero null characters
perhaps. But 2.X is destined to die anyway so I'm happy for it to only
be the default for unicode strings without implementing potentially
complex, wrong and slow heuristics.

Users can always register it themselves using addTypeEqualityFunc if
they want.

----------

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

From report at bugs.python.org  Fri Oct  2 12:58:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Oct 2009 10:58:48 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1254481128.81.0.527080714085.issue2986@psf.upfronthosting.co.za>


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

The popularity heuristic could be tuned to depend on the number N of
distinct elements in the sequence, and kick in if an element appears say
more than 1/(N**0.5) of the time.

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

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

From report at bugs.python.org  Fri Oct  2 13:14:30 2009
From: report at bugs.python.org (lekma)
Date: Fri, 02 Oct 2009 11:14:30 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>


New submission from lekma <lekmalek at gmail.com>:

It would be nice to have an obvious/simple way to document C exceptions
(especially when using the autoexception feature from Sphinx).

Something along:

PyObject *PyErr_Create(char *name, const char *doc)
    Creates and returns a new exception object.
    This behaves like PyErr_Create2() with base set to NULL.

PyObject *PyErr_Create2(char *name, const char *doc, PyObject *base)
    Creates and returns a new exception object.
    The name argument must be the name of the new exception, a C string
of the form module.class.
    If doc is non-NULL, it will be used to define the docstring for the
exception.
    if base is NULL, it creates a class object derived from Exception
(accessible in C as PyExc_Exception).

for py3k the signatures would be:
PyObject *PyErr_Create(const char *name, const char *doc)
PyObject *PyErr_Create2(const char *name, const char *doc, PyObject *base)

Internally, these functions would pass a dict to PyErr_NewException with
the key '__doc__' set to doc.

If there is support for this, I can provide patches for trunk and py3k.

----------
components: Interpreter Core
messages: 93439
nosy: lekma
severity: normal
status: open
title: C/API - Document exceptions
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Oct  2 13:14:43 2009
From: report at bugs.python.org (Koen van de Sande)
Date: Fri, 02 Oct 2009 11:14:43 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1254482083.53.0.431210223631.issue4120@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

Could msvc9compiler_stripruntimes.diff still be considered for 
inclusion in Python 2.6.3 (high priority?)?
A lot of .pyd's of third-party extensions are getting dependencies on 
MSVCR90 added to the .pyd, which makes them not work if the runtimes 
are not installed into the WinSxS folder and/or when embedding into 
other applications. For example, PIL encountered this problem recently. 
In essence, all Windows Python extensions built using setup.py 
build_ext encounter this problem.
What the patch does is edit the manifest file to remove only the 
dependency on Microsoft.VC90.CRT.

----------

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

From report at bugs.python.org  Fri Oct  2 13:23:08 2009
From: report at bugs.python.org (Koen van de Sande)
Date: Fri, 02 Oct 2009 11:23:08 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1254482588.01.0.0142652523959.issue4120@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

It probably won't make 2.6.3 as the final is just out. But can we have 
it for 2.6.4?
Here's a link to the relevant discussion on ImageSIG: http://
mail.python.org/pipermail/image-sig/2009-October/005918.html

Looking at my local extensions installed, Matplotlib has applied this 
patch, but PyGame and PIL have embedded manifests with dependencies on 
the runtime in their .pyd's.

The patch now does a text search/replace on an XML file, if you think 
this is bad style I could rewrit it to use proper XML parsing and 
writing.

----------

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

From report at bugs.python.org  Fri Oct  2 15:15:44 2009
From: report at bugs.python.org (Nathan Ball)
Date: Fri, 02 Oct 2009 13:15:44 +0000
Subject: [issue7034] While Loop Bug on a game of 21, help!
In-Reply-To: <1254489344.22.0.289121223356.issue7034@psf.upfronthosting.co.za>
Message-ID: <1254489344.22.0.289121223356.issue7034@psf.upfronthosting.co.za>


New submission from Nathan Ball <pixelhead777 at gmail.com>:

I'm learning Python in Computer Class... and I've gone nuts trying to 
figure out why my code for a 2-player game of 21 (blackjack without the 
gambling connotation, I guess... not to mention my innacuracy of 
dealing only one card to start (which I know isn't affecting my 
glitched code)) has a glitched While loop...

my while loop has a lot within it... which is what's making it so hard 
to debug...

If you can tell me why my code is so bugged, I beg of you, let me 
know...

(Oh, and my classmate is saying my code is too long for it... when I 
want it to look like a decent game and not a crapshoot. >.>)

----------
components: IDLE
files: 21-2Player.py
messages: 93442
nosy: PixelHead777
severity: normal
status: open
title: While Loop Bug on a game of 21, help!
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15019/21-2Player.py

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

From report at bugs.python.org  Fri Oct  2 15:20:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2009 13:20:49 +0000
Subject: [issue7034] While Loop Bug on a game of 21, help!
In-Reply-To: <1254489344.22.0.289121223356.issue7034@psf.upfronthosting.co.za>
Message-ID: <1254489649.94.0.691675359894.issue7034@psf.upfronthosting.co.za>


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

The bug tracker is for Python bugs, not for helping people to find bugs
in their programs.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 15:23:48 2009
From: report at bugs.python.org (PixelHead777)
Date: Fri, 02 Oct 2009 13:23:48 +0000
Subject: [issue7034] While Loop Bug on a game of 21, help!
In-Reply-To: <1254489344.22.0.289121223356.issue7034@psf.upfronthosting.co.za>
Message-ID: <1254489828.41.0.663345531787.issue7034@psf.upfronthosting.co.za>


PixelHead777 <pixelhead777 at gmail.com> added the comment:

(New to the site, sorry...)

----------

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

From report at bugs.python.org  Fri Oct  2 16:18:33 2009
From: report at bugs.python.org (Ole Laursen)
Date: Fri, 02 Oct 2009 14:18:33 +0000
Subject: [issue7035] codecs error handlers lack documentation
In-Reply-To: <1254493113.5.0.852242878975.issue7035@psf.upfronthosting.co.za>
Message-ID: <1254493113.5.0.852242878975.issue7035@psf.upfronthosting.co.za>


New submission from Ole Laursen <olau at iola.dk>:

import codecs
help(codecs.replace_errors)

results in 

replace_errors(...)
(END)

in Python 2.6. Interestingly, http://docs.python.org/library/codecs
actually says "Implements the replace error handling." Which is pretty
useless, though. :) Suggest at least copying the parenthesized notes in
the next-to-last paragraph under codecs.register to the docstrings.

I was looking for docs in the hope of finding something fancy ala
converting ? to ae, alas no cigar.

----------
assignee: georg.brandl
components: Documentation
messages: 93445
nosy: georg.brandl, olau
severity: normal
status: open
title: codecs error handlers lack documentation
type: feature request

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

From report at bugs.python.org  Fri Oct  2 16:26:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2009 14:26:21 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1254493581.22.0.320091719949.issue5097@psf.upfronthosting.co.za>


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

Oh, we sometimes keep bugs open for years around here, until someone
finds time to deal with them.  It's our collective memory...thanks for
taking a crack at the wording.  If you feel like turning it into a patch
against the documentation (which is in the Doc directory of a CVS
checkout, see http://www.python.org/dev for more info on how to generate
a patch), someone might get to it sooner.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Fri Oct  2 16:30:15 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2009 14:30:15 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1254493815.93.0.114935577587.issue5097@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Fri Oct  2 18:52:31 2009
From: report at bugs.python.org (noon)
Date: Fri, 02 Oct 2009 16:52:31 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1254502351.47.0.527833747906.issue3786@psf.upfronthosting.co.za>


Changes by noon <fbauzac at amadeus.com>:


----------
nosy: +noon

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

From report at bugs.python.org  Fri Oct  2 19:15:45 2009
From: report at bugs.python.org (Sebastian Thiel)
Date: Fri, 02 Oct 2009 17:15:45 +0000
Subject: [issue7036] Doc/reference/datamodel: Slots description needs update
In-Reply-To: <1254503745.39.0.693240836231.issue7036@psf.upfronthosting.co.za>
Message-ID: <1254503745.39.0.693240836231.issue7036@psf.upfronthosting.co.za>


New submission from Sebastian Thiel <byronimo at gmail.com>:

The section starting with:
"If a class defines a slot also defined in a base class, the instance
variable
  defined by the base class slot is inaccessible rendering the meaning
of the
  program undefined. [...]"

would need to be revisited as it claims that a check for this issue
might be added in future. As far as I can tell, it has been added in
Python 2.4 or earlier as I get a TypeError in that case.

The attached diff is my attempt to fix this issue.

Kind Regards, 
Sebastian

----------
assignee: georg.brandl
components: Documentation
files: docfix.diff
keywords: patch
messages: 93447
nosy: Byron, georg.brandl
severity: normal
status: open
title: Doc/reference/datamodel: Slots description needs update
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15020/docfix.diff

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

From report at bugs.python.org  Fri Oct  2 19:23:32 2009
From: report at bugs.python.org (lekma)
Date: Fri, 02 Oct 2009 17:23:32 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254504212.89.0.15138528486.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

First attempt at implementing this.
Diff is against trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file15021/issue7033_trunk.diff

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

From report at bugs.python.org  Fri Oct  2 19:24:27 2009
From: report at bugs.python.org (lekma)
Date: Fri, 02 Oct 2009 17:24:27 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254504267.23.0.8890170736.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

The same against py3k

----------
Added file: http://bugs.python.org/file15022/issue7033_py3k.diff

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

From report at bugs.python.org  Fri Oct  2 19:57:35 2009
From: report at bugs.python.org (Sebastian Thiel)
Date: Fri, 02 Oct 2009 17:57:35 +0000
Subject: [issue7036] Doc/reference/datamodel: Slots description needs update
In-Reply-To: <1254503745.39.0.693240836231.issue7036@psf.upfronthosting.co.za>
Message-ID: <1254506255.78.0.0495727959907.issue7036@psf.upfronthosting.co.za>


Sebastian Thiel <byronimo at gmail.com> added the comment:

Additional Information:

"multiple bases have instance lay-out conflict"

This happens only if I add __slots__ to the bases so that there is no
dict. I can reproduce this easily by indirectly deriving a class from
two bases that both define the same slot. 
It only happens if all classes define __slots__ so there is no dict.

class ac( object ):
    __slots__ = "a"

class bc( ac ):
    __slots__ = "b"

class cc( ac ):
    __slots__ = "c"

class cannotbecreated( bc,cc ):
     pass
     # raises an error.

Actually I don't know whether this is intended or if it is related to
the documentation section I pointed at.

----------

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

From report at bugs.python.org  Fri Oct  2 22:15:12 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:15:12 +0000
Subject: [issue7037] test_asynchat fails on os x 10.6
In-Reply-To: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>
Message-ID: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

Loads of outputs like
test_string_producer (test.test_asynchat.TestAsynchat_WithPoll) ... 
error: uncaptured python exception, closing channel 
<test.test_asynchat.echo_client at 0x3ca670> (<class 
'socket.error'>:[Errno 9] Bad file descriptor 
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|readwrite|107] 
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|handle_expt_event|441] [<string>|getsockopt|1] 
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.
py|_dummy|165])

Test says it passes, though. Complete output is attached.

----------
files: test_asynchat.fail
messages: 93452
nosy: chuck
severity: normal
status: open
title: test_asynchat fails on os x 10.6
versions: Python 2.6
Added file: http://bugs.python.org/file15023/test_asynchat.fail

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

From report at bugs.python.org  Fri Oct  2 22:22:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Oct 2009 20:22:36 +0000
Subject: [issue7037] test_asynchat fails on os x 10.6
In-Reply-To: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>
Message-ID: <1254514956.63.0.294218362154.issue7037@psf.upfronthosting.co.za>


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


----------
assignee:  -> josiahcarlson
components: +Library (Lib), Tests
nosy: +josiahcarlson
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Fri Oct  2 22:29:44 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:29:44 +0000
Subject: [issue7038] test_curses fails on os x 10.6
In-Reply-To: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>
Message-ID: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

test_curses
test test_curses crashed -- <class '_curses.error'>: endwin() returned 
ERR
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/test/re
grtest.py", line 549, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/test/te
st_curses.py", line 279, in <module>
    curses.endwin()
error: endwin() returned ERR
1 test failed:
    test_curses

----------
messages: 93453
nosy: chuck
severity: normal
status: open
title: test_curses fails on os x 10.6
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  2 22:33:08 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:33:08 +0000
Subject: [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

FAIL: test_get_python_inc 
(distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distuti
ls/tests/test_sysconfig.py", line 54, in test_get_python_inc
    self.assert_(os.path.isdir(inc_dir), inc_dir)
AssertionError: /Users/ronald/Projects/python/r263/Include

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 93454
nosy: chuck
severity: normal
status: open
title: test_distutils fails on os x 10.6
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  2 22:38:34 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 20:38:34 +0000
Subject: [issue7040] test_smtplib fails on os x 10.6
In-Reply-To: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
Message-ID: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

Output like:
testAUTH_PLAIN (test.test_smtplib.SMTPSimTests) ... error: uncaptured 
python exception, closing channel <test.test_smtplib.SimSMTPChannel 
127.0.0.1:54223 at 0x728468> (<class 'socket.error'>:[Errno 9] Bad file 
descriptor 
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|readwrite|107] 
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncor
e.py|handle_expt_event|441] [<string>|getsockopt|1] 
[/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.
py|_dummy|165])

Probably related to #7037 . Complete output attached.

----------
components: Library (Lib), Tests
files: test_smtplib.fail
messages: 93455
nosy: chuck
severity: normal
status: open
title: test_smtplib fails on os x 10.6
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15024/test_smtplib.fail

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

From report at bugs.python.org  Fri Oct  2 23:14:22 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 21:14:22 +0000
Subject: [issue7041] test_macostools fails on os x 10.6
In-Reply-To: <1254518062.04.0.658322870516.issue7041@psf.upfronthosting.co.za>
Message-ID: <1254518062.04.0.658322870516.issue7041@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

test_macostools
test_copy (test.test_macostools.TestMacostools) ... ERROR
test_mkalias (test.test_macostools.TestMacostools) ... ERROR
test_mkalias_relative (test.test_macostools.TestMacostools) ... ERROR
test_touched (test.test_macostools.TestMacostools) ... ok

======================================================================
ERROR: test_copy (test.test_macostools.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jan/src/python26/Lib/test/test_macostools.py", line 65, 
in test_copy
    macostools.copy(test_support.TESTFN, TESTFN2)
  File "/Users/jan/src/python26/Lib/plat-mac/macostools.py", line 114, 
in copy
    srcfss = File.FSSpec(src)
AttributeError: 'module' object has no attribute 'FSSpec'

======================================================================
ERROR: test_mkalias (test.test_macostools.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jan/src/python26/Lib/test/test_macostools.py", line 73, 
in test_mkalias
    macostools.mkalias(test_support.TESTFN, TESTFN2)
  File "/Users/jan/src/python26/Lib/plat-mac/macostools.py", line 46, in 
mkalias
    dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, 
unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'

======================================================================
ERROR: test_mkalias_relative (test.test_macostools.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jan/src/python26/Lib/test/test_macostools.py", line 88, 
in test_mkalias_relative
    macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix)
  File "/Users/jan/src/python26/Lib/plat-mac/macostools.py", line 46, in 
mkalias
    dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, 
unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'

----------------------------------------------------------------------
Ran 4 tests in 0.006s

FAILED (errors=3)
test test_macostools failed -- errors occurred; run in verbose mode for 
details
1 test failed:
    test_macostools

----------
components: Library (Lib), Tests
messages: 93456
nosy: chuck
severity: normal
status: open
title: test_macostools fails on os x 10.6
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  2 23:18:30 2009
From: report at bugs.python.org (Jan Hosang)
Date: Fri, 02 Oct 2009 21:18:30 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

======================================================================
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jan/src/python26/Lib/test/test_signal.py", line 368, in 
test_itimer_virtual
    self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0))
AssertionError: (0.17993600000000001, 0.20000000000000001) != (0.0, 0.0)

----------------------------------------------------------------------

Complete output attached.

----------
components: Library (Lib), Tests
files: test_signal.fail
messages: 93457
nosy: chuck
severity: normal
status: open
title: test_signal fails on os x 10.6
versions: Python 2.6
Added file: http://bugs.python.org/file15025/test_signal.fail

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

From report at bugs.python.org  Fri Oct  2 23:37:40 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 02 Oct 2009 21:37:40 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1254519460.84.0.837135424443.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

There are two easy to fix issues with the
msvc9compiler_stripruntimes.diff patch: 1) the dependency for 64-bit
VC90.CRT is not removed and 2) the VC90.CRT dependency is removed also
from executables, which will fail to run. A revised patch is attached.
This is used to build the Matplotlib binaries for Windows and also works
for numpy, pygame and PIL.

----------
nosy: +cgohlke
Added file: http://bugs.python.org/file15026/msvc9compiler_stripruntimes_revised.diff

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

From report at bugs.python.org  Sat Oct  3 00:46:40 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 02 Oct 2009 22:46:40 +0000
Subject: [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254523600.99.0.252891124105.issue7039@psf.upfronthosting.co.za>


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

What version of Python are you running precisely ?

----------
assignee:  -> tarek
components: +Distutils -Library (Lib), Tests
nosy: +tarek

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

From report at bugs.python.org  Sat Oct  3 01:36:17 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Oct 2009 23:36:17 +0000
Subject: [issue7037] test_asynchat fails on os x 10.6
In-Reply-To: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>
Message-ID: <1254526577.78.0.155233134638.issue7037@psf.upfronthosting.co.za>


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

This is a duplicate of Issue5798, the fix for which has not been 
backported to 2.6.  It is also not limited to OS X 10.6.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Oct  3 01:57:52 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Oct 2009 23:57:52 +0000
Subject: [issue7038] test_curses fails on os x 10.6
In-Reply-To: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>
Message-ID: <1254527872.01.0.531094842848.issue7038@psf.upfronthosting.co.za>


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

Running the test standalone works for me running under Terminal.app:

$ echo $TERM
xterm-color
$ cd /Library/Frameworks/Python.framework/Versions/2.6
$ bin/python2.6 lib/python2.6/test/regrtest.py -u curses test_curses
test_curses
1 test OK.

It's probably failing because of your terminal type or some other 
environment issue.  How are you running it?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Oct  3 01:58:20 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 02 Oct 2009 23:58:20 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1254527900.9.0.593080482935.issue6516@psf.upfronthosting.co.za>


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

done in r75192 and r75194. Thanks Till !

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

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

From report at bugs.python.org  Sat Oct  3 02:29:21 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 03 Oct 2009 00:29:21 +0000
Subject: [issue7043] test_urllib: constructLocalFileUrl returns invalid URLs
	on Windows
In-Reply-To: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
Message-ID: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>


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

This error happens on Windows. The culprit seems to be the
`constructLocalFileUrl` method that is constructing invalid URLs.

Traceback (most recent call last):
  File "C:\Python26\lib\test\test_urllib.py", line 241, in test_copy
    test_support.TESTFN), second_temp)
  File "C:\Python26\lib\urllib.py", line 94, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File "C:\Python26\lib\urllib.py", line 238, in retrieve
    fp = self.open(url, data)
  File "C:\Python26\lib\urllib.py", line 206, in open
    return getattr(self, name)(url)
  File "C:\Python26\lib\urllib.py", line 468, in open_file
    return self.open_local_file(url)
  File "C:\Python26\lib\urllib.py", line 482, in open_local_file
    raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 22] The filename, directory name, or volume label syntax
is incorrect: '\\\\\\C|\\DOCUME~1\\apy\\LOCALS~1\\Temp\\autotest\\@test'

----------
components: Tests
messages: 93463
nosy: srid
severity: normal
status: open
title: test_urllib: constructLocalFileUrl returns invalid URLs on Windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct  3 02:30:53 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Oct 2009 00:30:53 +0000
Subject: [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254529853.16.0.0721367285039.issue7039@psf.upfronthosting.co.za>


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

I don't know how it works on other platforms but test_get_python_inc is 
incorrect when run, as in this case, from a user-installed python rather 
than as part of a build of python.

The relevant code in test_sysconfig.py:

>>> (srcdir,) = sysconfig.get_config_vars('srcdir')
>>> srcdir
'/Users/ronald/Projects/python/r263'
>>> inc_dir = sysconfig.get_python_inc()
>>> inc_dir
'/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6'

That's where Python.h exists in an OS X framework install.  The srcdir 
captured is useless on other than the build machine; there is none.  
(People who build OS X python installers don't see this problem when 
they run the tests on a machine which happens to have a build directory 
in the same location.)

----------
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Sat Oct  3 02:42:45 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Oct 2009 00:42:45 +0000
Subject: [issue7040] test_smtplib fails on os x 10.6
In-Reply-To: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
Message-ID: <1254530565.79.0.514340667943.issue7040@psf.upfronthosting.co.za>


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

Appears to be a duplicate of Issue3620.  It is also not limited to 10.6.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Oct  3 02:53:55 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 03 Oct 2009 00:53:55 +0000
Subject: [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254531235.26.0.46109719752.issue7039@psf.upfronthosting.co.za>


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

Ok thanks,

----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Oct  3 03:06:04 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Oct 2009 01:06:04 +0000
Subject: [issue7041] test_macostools fails on os x 10.6
In-Reply-To: <1254518062.04.0.658322870516.issue7041@psf.upfronthosting.co.za>
Message-ID: <1254531964.34.0.541417126438.issue7041@psf.upfronthosting.co.za>


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

This test works for me using the 2.6.3 installer which is 32-bit only.

It will fail, though, on a 64-bit build since Apple does not supply 64-bit 
versions of the Carbon frameworks used by these modules.  That's why they 
are deprecated and have been removed in python 3.  You can see the same 
failure using Apple's 64-bit python 2.6 in 10.6. You'll also see it on 
10.5 with 64-bit.

----------
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Sat Oct  3 03:23:01 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 03 Oct 2009 01:23:01 +0000
Subject: [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254532981.51.0.0651512905874.issue7039@psf.upfronthosting.co.za>


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

done in r75199 Thanks ! (this problem was fixed in trunk/py3k earlier,
so only concerns 2.6 branch)

----------
status: open -> closed
versions:  -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Oct  3 03:28:03 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Sat, 03 Oct 2009 01:28:03 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1254533283.78.0.0396619259152.issue6845@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

I attached some tests.

----------
Added file: http://bugs.python.org/file15027/issue6845.diff

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

From report at bugs.python.org  Sat Oct  3 03:49:45 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Oct 2009 01:49:45 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254534585.79.0.431228981914.issue7042@psf.upfronthosting.co.za>


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

test_signal does not fail for me on 10.6 using the python.org 2.6.3 
installer (which is 32-bit).  The test hangs (presumably in the wait 
loop) with a 10.6 64-bit build of Python 2.6.3rc1.  FWIW, the 2.6.3 
test_signal seems to run OK with Apple's 64-bit python2.6.2 in 10.6. 
What kind of build and on what kind of machine were you running this?

There are other issues open that report similar problems running 
test_signal on other OS's: http://bugs.python.org/issue5972, which was 
reported against Red Hat Linux 4.1.2, and possibly 
http://bugs.python.org/issue3864 on FreeBSD.  Perhaps there's a common 
thread here.

----------
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Sat Oct  3 03:54:14 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Oct 2009 01:54:14 +0000
Subject: [issue7039] test_distutils fails on os x 10.6
In-Reply-To: <1254515588.38.0.10487932532.issue7039@psf.upfronthosting.co.za>
Message-ID: <1254534854.38.0.888536475706.issue7039@psf.upfronthosting.co.za>


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

Thanks, I should have looked in trunk first.  I thought you had fixed this 
already.

----------

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

From report at bugs.python.org  Sat Oct  3 04:35:57 2009
From: report at bugs.python.org (Josh Cogliati)
Date: Sat, 03 Oct 2009 02:35:57 +0000
Subject: [issue7028] Add int.hex for symmetry with float.hex
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254537357.4.0.657974765029.issue7028@psf.upfronthosting.co.za>


Josh Cogliati <jjcogliati-r1 at yahoo.com> added the comment:

Well, I think think I would at least like the sections in the Library
reference documentation should mention the other functions.  I.e. the
following should have cross references:

A. 2. Built-in Functions hex() should cross reference float.hex()
B. 2. Built-in Functions float() should cross reference float.fromhex()
C. 5.4.3. Additional Methods on Float float.hex() should cross reference
hex()
D. 5.4.3. Additional Methods on Float float.fromhex() should cross
reference int(x,16)

As well, the documentation strings for hex, float.hex and float.fromhex
should mention the alternative functions. 

I am not sure about B, but I think in the documentation the alternative
functions should be mentioned.  

I can prepare a documentation patch, if you think it would be useful (it
may take a week or two). I would not have filed this bug if A. had
existed since the hex documentation was the first place I looked.  

Thank you.

----------

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

From report at bugs.python.org  Sat Oct  3 05:30:55 2009
From: report at bugs.python.org (jweber)
Date: Sat, 03 Oct 2009 03:30:55 +0000
Subject: [issue7044] urllib.urlopen crashes when used on Mac OS 10.6.1 through
	a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>


New submission from jweber <jacob at jacobweber.com>:

In Python 2.6.3 on Mac OS 10.6.1, there is a bug in 
lib/python2.6/urllib.py, line 1367. The variable hostIP is used before 
it's defined. You can fix it by adding "hostIP = None" at around line 
1355. I got the following exception when calling urllib.urlopen using a 
proxy:

  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 87, in urlopen
    return opener.open(url)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 206, in open
    return getattr(self, name)(url)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 317, in open_http
    if proxy_bypass(realhost):
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1398, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1367, in proxy_bypass_macosx_sysconf
    if hostIP is None:
UnboundLocalError: local variable 'hostIP' referenced before assignment

----------
assignee: ronaldoussoren
components: Macintosh
messages: 93473
nosy: jweber, ronaldoussoren
severity: normal
status: open
title: urllib.urlopen crashes when used on Mac OS 10.6.1 through a proxy
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sat Oct  3 05:39:10 2009
From: report at bugs.python.org (jweber)
Date: Sat, 03 Oct 2009 03:39:10 +0000
Subject: [issue7044] urllib.urlopen crashes when used on Mac OS 10.6.1 through
	a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1254541150.59.0.605965017095.issue7044@psf.upfronthosting.co.za>


jweber <jacob at jacobweber.com> added the comment:

Let me know if you need me to create a test case....it doesn't seem to 
happen in all situations.

----------

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

From report at bugs.python.org  Sat Oct  3 05:46:54 2009
From: report at bugs.python.org (Arc Riley)
Date: Sat, 03 Oct 2009 03:46:54 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>


New submission from Arc Riley <arcriley at gmail.com>:

The following is a minimal example which does not work under Python
3.1.1 but functions as expected on Pyhton 2.6 and 3.0.

Python 3.1.1 believes the single UTF-8 glyph is two entirely different
(and illegal) unicode characters:

Traceback (most recent call last):
  File "t.py", line 2, in <module>
    print('?')
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud801' in
position 0: surrogates not allowed

Test system is Ubuntu 9.10-beta 32-bit

----------
components: Interpreter Core
files: t.py
messages: 93475
nosy: ArcRiley
severity: normal
status: open
title: utf-8 encoding error
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15028/t.py

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

From report at bugs.python.org  Sat Oct  3 06:09:16 2009
From: report at bugs.python.org (Arc Riley)
Date: Sat, 03 Oct 2009 04:09:16 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254542956.92.0.539566996209.issue7045@psf.upfronthosting.co.za>


Arc Riley <arcriley at gmail.com> added the comment:

While t.py only bugs on 3.1, the following happens with 3.0 as well:

>>> line = '??????'
>>> first = '?'
>>> first
'?'
>>> line[0]
'\ud801'
>>> line[0] == first
False

And with 2.6:
>>> line = u'??????'
>>> first = u'?'
>>> first
u'\ud801\udc51'

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

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

From report at bugs.python.org  Sat Oct  3 06:28:58 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 03 Oct 2009 04:28:58 +0000
Subject: [issue7043] test_urllib: constructLocalFileUrl returns invalid URLs
	on Windows
In-Reply-To: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
Message-ID: <1254544138.03.0.905017003986.issue7043@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


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

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

From report at bugs.python.org  Sat Oct  3 07:12:34 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Oct 2009 05:12:34 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254546754.46.0.57192665446.issue7006@psf.upfronthosting.co.za>


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

hasattr(type(x), "__call__") is technically a more valid replacement due
to the usual matter of metaclass confusion.

(Although putting special methods on instance objects is a recipe for
trouble in more ways than just this one).

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Sat Oct  3 07:13:15 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Oct 2009 05:13:15 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254546795.94.0.210946648663.issue7006@psf.upfronthosting.co.za>


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

Although we should seriously consider properly exposing special method
lookup at the Python level...

----------

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

From report at bugs.python.org  Sat Oct  3 08:13:29 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Oct 2009 06:13:29 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254550409.27.0.282122052898.issue7006@psf.upfronthosting.co.za>


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

Benjamin already replaced hasattr(x, "__call__") with hasattr(type(x),
"__call__") in the Python 3.0 "What's New" in r75090 and r75094, but
this still doesn't match completely the behavior of callable():

>>> class Foo(object): pass
...
>>> foo = Foo()
>>> callable(foo)
False
>>> hasattr(type(foo), '__call__')
True
>>> foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'Foo' object is not callable

There are also other places where hasattr(x, "__call__") is still
suggested/used (e.g. PEP3100).

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

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

From report at bugs.python.org  Sat Oct  3 08:27:25 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sat, 03 Oct 2009 06:27:25 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254551245.72.0.672178186082.issue7042@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

This is a 64 bit machine and the test failed for the checkout of the 
python26-maint branch. I just configured and made it without any flags. 
(Does that produce a 64 bit build?)

----------

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

From report at bugs.python.org  Sat Oct  3 10:16:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 08:16:08 +0000
Subject: [issue7019] unmarshaling of artificial strings can produce funny
	longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254557768.1.0.767139847353.issue7019@psf.upfronthosting.co.za>


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

2.6 fix applied in r75203.

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

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

From report at bugs.python.org  Sat Oct  3 11:12:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Oct 2009 09:12:05 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254561125.5.0.737933643659.issue7045@psf.upfronthosting.co.za>


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

I can't reproduce that; it prints fine for me.

Notice that it is perfectly fine for Python to represent this as two
code points in UCS-2 mode (so that len(s)==2); this is called UTF-16.

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

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

From report at bugs.python.org  Sat Oct  3 11:20:20 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Oct 2009 09:20:20 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254561620.44.0.232006112783.issue7042@psf.upfronthosting.co.za>


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

By default, 10.6 prefers to run 64-bit architectures when available.  You 
can easily tell whether a python 2.x is running as 32-bit or 64-bit by 
checking sys.maxint:

$ /usr/local/bin/python2.6 -c 'import sys; print sys.maxint'
2147483647
$ /usr/bin/python2.6 -c 'import sys; print sys.maxint'
9223372036854775807

----------

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

From report at bugs.python.org  Sat Oct  3 11:30:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Oct 2009 09:30:09 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254562209.38.0.15943382621.issue7033@psf.upfronthosting.co.za>


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

Sounds like a useful new API. Two comments:

* The version without *base* is not needed.  Passing an explicit NULL
for *base* is easy enough.
* The name "PyErr_Create" is needlessly different from
"PyErr_NewException".  Something like "PyErr_NewExceptionWithDoc" is better.

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

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

From report at bugs.python.org  Sat Oct  3 11:40:43 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sat, 03 Oct 2009 09:40:43 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254562843.19.0.47725931409.issue7042@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

$ ./python.exe -c 'import sys; print sys.maxint'
9223372036854775807

----------

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

From report at bugs.python.org  Sat Oct  3 12:22:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Oct 2009 10:22:01 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254565321.02.0.79797717449.issue7045@psf.upfronthosting.co.za>


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

I can't reproduce it either on Ubuntu 9.04 32-bit. I tried both from the
terminal and from the file, using Py3.2a0.

As Martin said, the fact that in narrow builds of Python the codepoints
outside the BMP are represented with two surrogate pairs is a known
"issue". This is how UTF-16 works, even if it has some problematic
side-effects.
In your example 'line[0]' is not equal to 'first' because line[0] is the
codepoint of the first surrogate and 'first' is a scalar value that
represents the SHAVIAN LETTER TOT (U+010451).

Regarding the traceback you pasted in the first post, have you used
print('?') or print(line[0])?

This is what I get using line[0]:
>>> line = '??????'
>>> first = '?'
>>> print(line[0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud801' in
position 0: surrogates not allowed

In this case you are getting an error because lone surrogates are
invalid and they can't be encoded. If you use line[:2] instead it works
because it takes both the surrogates:

>>> print(line[0:2])
?
>>> first == line[0:2]
True

If you really got that error with print('?'), then #3297 could be related.

Can you also try this and see what it prints?
>>> import sys
>>> sys.maxunicode

----------
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Sat Oct  3 12:22:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 10:22:03 +0000
Subject: [issue7028] Add int.hex for symmetry with float.hex
In-Reply-To: <1254365513.69.0.169438970991.issue7028@psf.upfronthosting.co.za>
Message-ID: <1254565323.33.0.761555930361.issue7028@psf.upfronthosting.co.za>


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

Rejecting the request to add int.hex.

I've added a note to the hex() docs pointing to float.hex(), in revisions 
r75025 through r75028.

It doesn't really seem worth adding pointers from float.hex and 
float.fromhex back to integer analogues:  it's the float methods that are 
hard to find, not the int methods.

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

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

From report at bugs.python.org  Sat Oct  3 12:25:31 2009
From: report at bugs.python.org (Trundle)
Date: Sat, 03 Oct 2009 10:25:31 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254565531.58.0.936255809067.issue7006@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

As every type is an instance of `type`, every type also has a
`__call__` attribute which means ``hasattr(type(x), '__call__')`` is
always true. `callable()` checks whether `tp_call` is set on the type,
which cannot be done in Python directly.

----------
nosy: +Trundle

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

From report at bugs.python.org  Sat Oct  3 15:15:18 2009
From: report at bugs.python.org (Arc Riley)
Date: Sat, 03 Oct 2009 13:15:18 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254575718.37.0.363780813655.issue7045@psf.upfronthosting.co.za>


Arc Riley <arcriley at gmail.com> added the comment:

Python 3.1.1 (r311:74480, Sep 13 2009, 22:19:17)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxunicode
1114111
>>> u = '?'
>>> print(u)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud801' in
position 0: surrogates not allowed

----------

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

From report at bugs.python.org  Sat Oct  3 15:30:56 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:30:56 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

In many cases, decimal.py sets InvalidOperation instead of
DivisionImpossible or DivisionUndefined.

Mark, could I persuade you to isolate these cases by running a modified
deccheck2.py from mpdecimal (See attachment), which does not suppress
differences in the division functions?

----------
files: div-deccheck2.py
messages: 93490
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: use DivisionImpossible and DivisionUndefined
Added file: http://bugs.python.org/file15029/div-deccheck2.py

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

From report at bugs.python.org  Sat Oct  3 15:46:49 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:46:49 +0000
Subject: [issue7047] decimal.py: NaN payload conversion
In-Reply-To: <1254577609.23.0.3782240527.issue7047@psf.upfronthosting.co.za>
Message-ID: <1254577609.23.0.3782240527.issue7047@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

decimal.py sets InvalidOperation if the payload of a NaN is too large:

>>> c = getcontext()
>>> c.prec = 4
>>> c.create_decimal("NaN12345")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 3797, in create_decimal
    "diagnostic info too long in NaN")
  File "/usr/lib/python2.7/decimal.py", line 3733, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: diagnostic info too long in NaN


decNumber (and fastdec) set ConversionSyntax.

----------
messages: 93491
nosy: skrah
severity: normal
status: open
title: decimal.py: NaN payload conversion

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

From report at bugs.python.org  Sat Oct  3 15:47:29 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:47:29 +0000
Subject: [issue7047] decimal.py: NaN payload conversion
In-Reply-To: <1254577609.23.0.3782240527.issue7047@psf.upfronthosting.co.za>
Message-ID: <1254577649.62.0.0192726670883.issue7047@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sat Oct  3 15:53:18 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:53:18 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 2
>>> c.logb(Decimal("1E123456"))
Decimal('123456')
>>> 

This result agrees with the result of decNumber, but the spec says:
"All results are exact unless an integer result does not fit in the
available precision."

My interpretation is that the result should be 1.2E+5.

----------
messages: 93492
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: logb: round the result if it is greater than prec

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

From report at bugs.python.org  Sat Oct  3 15:59:24 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 13:59:24 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

If precision 1 is aupported, the following results should not be NaN:

Python 2.7a0 (trunk:74738, Sep 10 2009, 11:50:08) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> setcontext(Context(prec=1, rounding=ROUND_UP,
Emin=-999999999999999999, Emax=999999999999999999, capitals=1, flags=[],
traps=[]))
>>> pow(Decimal(0), Decimal(3), Decimal(70))
Decimal('NaN')
>>> pow(Decimal(3), Decimal(0), Decimal(70))
Decimal('NaN')
>>>

----------
messages: 93493
nosy: skrah
severity: normal
status: open
title: decimal.py: NaN result in pow(x, y, z) with prec 1

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

From report at bugs.python.org  Sat Oct  3 16:00:25 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 14:00:25 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254578425.86.0.92036055887.issue7049@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sat Oct  3 16:48:19 2009
From: report at bugs.python.org (Mark Fitzgerald)
Date: Sat, 03 Oct 2009 14:48:19 +0000
Subject: [issue2821] unittest.py sys.exit error
In-Reply-To: <1210532457.78.0.053406582463.issue2821@psf.upfronthosting.co.za>
Message-ID: <1254581299.98.0.709700812214.issue2821@psf.upfronthosting.co.za>


Mark Fitzgerald <mark.fitzgerald2 at sympatico.ca> added the comment:

Agreed that this is clearly not a bug.  One way to get the desired
behavior from IDLE is to move up to Python 2.7a0+ or Python 3.1.1+,
where the 'exit' parameter of unittest.main(), which when set to False,
disables the sys.exit() call.

Alternatively, in 2.5, just create your own TextTestRunner, as described
in the 2.5.2 docs:

suite = unittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)
unittest.TextTestRunner(verbosity=2).run(suite)

----------
nosy: +mfitz

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

From report at bugs.python.org  Sat Oct  3 16:54:34 2009
From: report at bugs.python.org (Mark Fitzgerald)
Date: Sat, 03 Oct 2009 14:54:34 +0000
Subject: [issue7050] (x,y) += (1,2) crashes IDLE
In-Reply-To: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>
Message-ID: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>


New submission from Mark Fitzgerald <mark.fitzgerald2 at sympatico.ca>:

Start up IDLE.  Type "(x,y) += (1,2)" (without the double-quotes), then
press Enter.  IDLE unexpectedly terminates without message, pop-up, or
warning.  Admittedly, this line of code is likely not legal, but
shouldn't it just raise SyntaxError?

----------
components: IDLE
messages: 93495
nosy: mfitz
severity: normal
status: open
title: (x,y) += (1,2) crashes IDLE
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Oct  3 16:55:32 2009
From: report at bugs.python.org (Mark Fitzgerald)
Date: Sat, 03 Oct 2009 14:55:32 +0000
Subject: [issue7050] Augmented assignment of tuple crashes IDLE
In-Reply-To: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>
Message-ID: <1254581732.53.0.582456025496.issue7050@psf.upfronthosting.co.za>


Changes by Mark Fitzgerald <mark.fitzgerald2 at sympatico.ca>:


----------
title: (x,y) += (1,2) crashes IDLE -> Augmented assignment of tuple crashes IDLE

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

From report at bugs.python.org  Sat Oct  3 17:26:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 15:26:19 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1254583579.12.0.787523153323.issue7046@psf.upfronthosting.co.za>


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

Just to be clear, the decimal context doesn't (and shouldn't) know about DivisionImpossible:  there's 
no DivisionImpossible signal or trap described in the specification, but just a DivisionImpossible 
heading in the 'exceptional conditions' section of the spec.  And that DivisionImpossible condition 
signals InvalidOperation (according to the spec).  (And similarly for DivisionUndefined.)

So I don't think decimal.py is in violation of the specification here.

But decimal.py could be changed so that a call to _raise_error(context, DivisionImpossible, ...)
results in the DivisionImpossible exception being raised instead of the InvalidOperation exception.
This shouldn't break anything, since DivisionImpossible is a subclass of InvalidOperation.

Note that the appropriate sections of decimal.py do already raise the right conditions (unless some 
have been missed):  e.g., in Decimal._divide, we have the lines:

    # Here the quotient is too large to be representable                                                                                                                                              
    ans = context._raise_error(DivisionImpossible,
                               'quotient too large in //, % or divmod')

But the Context._raise_error method currently translates all the exceptional conditions to their 
corresponding signals, hence raises InvalidOperation in this case.

----------

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

From report at bugs.python.org  Sat Oct  3 17:30:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 15:30:53 +0000
Subject: [issue7047] decimal.py: NaN payload conversion
In-Reply-To: <1254577609.23.0.3782240527.issue7047@psf.upfronthosting.co.za>
Message-ID: <1254583853.97.0.723085574961.issue7047@psf.upfronthosting.co.za>


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

This is essentially the same issue as issue 7046:  the relevant lines in 
decimal.py read:

    if d._isnan() and len(d._int) > self.prec - self._clamp:
        return self._raise_error(ConversionSyntax,
                                     "diagnostic info too long in NaN")

and again, the Context._raise_error method translates the 
ConversionSyntax exceptional condition to the corresponding 
InvalidOperation signal.

Closing as a duplicate, just so we can keep everything one place.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> decimal.py: use DivisionImpossible and DivisionUndefined

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

From report at bugs.python.org  Sat Oct  3 17:33:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 15:33:05 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1254583985.67.0.663911461993.issue7046@psf.upfronthosting.co.za>


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

Closed issue 7047 as a duplicate of this one:  
_raise_error(ConversionSyntax) also raises (if trapped) the 
InvalidOperation exception, when it could reasonably raise 
ConversionSyntax instead.  It's the same cause as above:  _raise_error 
translates each exceptional condition to the corresponding signal.

----------

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

From report at bugs.python.org  Sat Oct  3 17:33:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 15:33:57 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1254584037.22.0.444102695035.issue7046@psf.upfronthosting.co.za>


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


----------
assignee:  -> mark.dickinson
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Oct  3 17:52:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 15:52:00 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254585120.04.0.727006476873.issue7049@psf.upfronthosting.co.za>


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

This behaviour was deliberate:  since the standard doesn't cover three-
argument pow, I more-or-less made up my own rules here.  :)

In this case, I (somewhat arbitrarily) decided that to ensure that any 
possible pow(a, b, m) result could be represented, m should be strictly 
less than 10**current_precision.  In general, you'd expect to make lots
of pow(a, b, m) calls with the same m and differing a and b;  it seems 
less error-prone to have them all these calls fail/pass together than 
have those with small results pass, and those with larger results fail.

Not that I expect there's a single person on this planet who's using 
three-argument pow with the Decimal type.  :)

Looking back at this, I'm not quite sure why I chose 'strictly less 
than' rather than 'less than or equal to'.

----------

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

From report at bugs.python.org  Sat Oct  3 18:10:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 16:10:36 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254586236.1.0.285686197207.issue7048@psf.upfronthosting.co.za>


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

Hmm.  The problem here is that the specification says nothing at all 
about what should happen if the integer result does *not* fit in the 
available precision, so in this case we went with the decNumber 
behaviour.

Rather than rounding, I'd say that a more useful result in this case 
would be to signal InvalidOperation, on the basis that an inexact result 
from logb is likely to invalidate most uses of it.

Maybe we should ask Mike Cowlishaw what the intended behaviour here is?

IEEE 754-2008 (section 5.3.3) requires that languages define a 
'logBFormat' type that's always big enough to hold the logB result.  If 
the result is a Decimal, one way to ensure this would be to place 
constraints on the allowable values emax and emin for a given precision.

----------

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

From report at bugs.python.org  Sat Oct  3 18:23:05 2009
From: report at bugs.python.org (Naoki INADA)
Date: Sat, 03 Oct 2009 16:23:05 +0000
Subject: [issue5911] built-in compile() should take encoding option.
In-Reply-To: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>
Message-ID: <1254586985.3.0.142923827652.issue5911@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

add sample implementation.

----------
keywords: +patch
Added file: http://bugs.python.org/file15030/compile_with_encoding.patch

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

From report at bugs.python.org  Sat Oct  3 20:13:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 18:13:48 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254593628.03.0.876039901628.issue7049@psf.upfronthosting.co.za>


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

Unless anyone else disagrees, I'm going to call this a 'won't fix':  I'm 
happy with the current behaviour.  I would like to relax the condition on 
the modulus from 'modulus < 10**prec' to 'modulus <= 10**prec', though, so 
I'm leaving the issue open for that.

----------
assignee:  -> mark.dickinson
components: +Library (Lib)
priority:  -> low
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Oct  3 20:46:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 18:46:00 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254595560.04.0.392386323416.issue7049@psf.upfronthosting.co.za>


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

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file15031/issue7049.patch

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

From report at bugs.python.org  Sat Oct  3 20:59:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Oct 2009 18:59:16 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

The docs for 'g' say "This prints the number as a fixed-point number,
unless the number is too large." Could you please explain what exactly
constitutes "too large"?

----------
assignee: eric.smith
messages: 93504
nosy: benjamin.peterson, eric.smith
severity: normal
status: open
title: 'g'/'G' format docs need a little more explanation

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

From report at bugs.python.org  Sat Oct  3 21:03:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 19:03:48 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1254596628.16.0.384622883186.issue7051@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sat Oct  3 21:44:15 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 03 Oct 2009 19:44:15 +0000
Subject: [issue7050] Augmented assignment of tuple crashes IDLE
In-Reply-To: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>
Message-ID: <1254599055.01.0.680030295227.issue7050@psf.upfronthosting.co.za>


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

>From the plain console:
>>> a, b +=2
SystemError: invalid node type (24) for augmented assignment

Python 3.0 used to be correct:
SyntaxError: illegal expression for augmented assignment

----------
assignee:  -> benjamin.peterson
nosy: +amaury.forgeotdarc, benjamin.peterson

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

From report at bugs.python.org  Sat Oct  3 22:23:44 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Oct 2009 20:23:44 +0000
Subject: [issue7050] Augmented assignment of tuple crashes IDLE
In-Reply-To: <1254581674.88.0.706780841215.issue7050@psf.upfronthosting.co.za>
Message-ID: <1254601424.55.0.375360548799.issue7050@psf.upfronthosting.co.za>


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

Good catch! Fixed in r75223.

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

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

From report at bugs.python.org  Sat Oct  3 22:25:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Oct 2009 20:25:20 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1254601520.52.0.315734573871.issue7051@psf.upfronthosting.co.za>


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

For 'g' formatting (either {} style or %-style) with precision p >= 1, I believe fixed-
point is used if and only if the formatted value satisfies

  1e-4 <= abs(formatted_value) < 10**precision.

Note that the 'formatted value' refers to the value rounded to p significant figures, 
not the original value of the number being formatted.  For example, in '%.6g' % 
9.999999e-5, the float rounded to 6 places is 1e-4, so the result is '0.0001', using 
fixed-point.  But '%.6g' % 9.999994e-5 gives '9.99999e-05'.

----------

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

From report at bugs.python.org  Sat Oct  3 23:20:25 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 03 Oct 2009 21:20:25 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1254604825.92.0.877413540987.issue6992@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I wonder what does Guido think about this bikeshed?

----------

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

From report at bugs.python.org  Sun Oct  4 00:06:48 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 22:06:48 +0000
Subject: [issue7046] decimal.py: use DivisionImpossible and DivisionUndefined
In-Reply-To: <1254576656.46.0.369353081628.issue7046@psf.upfronthosting.co.za>
Message-ID: <1254607608.88.0.541939145191.issue7046@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks for the explanation, and I agree that decimal.py is perfectly
correct. I based the report on the fact that decNumber updates the
context status with e.g. Division_impossible. But Division_impossible is
one of the flags that form IEEE_754_Invalid_operation, so presumably the
intention is to signal IEEE_754_Invalid_operation by means of flagging
Division_impossible.

On a side note, I find the distinction between signals and exceptional
conditions (mandated by the spec, as you pointed out) needlessly
complicated and I'm happy to see that note 5 under "Abstract
representation of context" says this might change in the future.

I'm all for raising DivisionImpossible, if it is not too much trouble.

----------

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

From report at bugs.python.org  Sun Oct  4 00:08:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Oct 2009 22:08:11 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254607691.53.0.59886535243.issue5395@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Sun Oct  4 00:14:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 03 Oct 2009 22:14:06 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254608046.64.0.902494338782.issue7045@psf.upfronthosting.co.za>


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

The page:
http://www.fileformat.info/info/unicode/char/d801/index.htm
has a big warning saying that "U+D801 is not a valid unicode character."

The problem is similar to issue6697, and lead to the same question:
should python validate utf-8 input, and refuse invalid unicode characters?

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

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

From report at bugs.python.org  Sun Oct  4 00:17:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Oct 2009 22:17:20 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters
	are	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1254608240.78.0.099236867666.issue6697@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Sun Oct  4 00:36:57 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2009 22:36:57 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254609417.64.0.698028290241.issue7049@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I don't think early abortion based on m and the current precision is a
good idea. Then we have the situation that this works (prec=4):

(Decimal(7) ** 2) % 100000

But this does not:

pow(Decimal(7), 2, 100000)

----------

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

From report at bugs.python.org  Sun Oct  4 00:37:34 2009
From: report at bugs.python.org (Paul Jimenez)
Date: Sat, 03 Oct 2009 22:37:34 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1254609454.97.0.969042025037.issue1462525@psf.upfronthosting.co.za>


Paul Jimenez <pj at place.org> added the comment:

Senthil wrote:
> > Senthil <orsenthil at gmail.com> added the comment:
> >
> > Hello Paul, 
> > Have you beeing keeping track of urlparse changes in Python2.6? 

No - do you have pointers to the particular changes you're
referring to?  I've done a bit of trying to catch up by searching
the mailing list, but want to make sure I know what you're
referring to in particular.

> > I 
> > anaylzed your patch and read through the RFC3986 and have the 
> > following comments:
> >
> > 1) The usage of this module is very diffirent from the current 
> > urlparse module's usage. It might be that this module was designed to 
> > co-exist with urlparse, providing certain additional functionalities. 
> > But inorder to replace urlparse, I find this module is "Backward 
> > Incompatible with the code base". 
> >
> > Some comments extra features provided /claims of this module.
> >   

Yes, there was no design goal of backward compatibility.

> > 2) The module provides URI handling framework that includes default 
> > URI Parsers for common URI Schemes.
> >     - RFC3986 specifies that scheme handling part is left to the 
> > separate RFC describing the schemes. 
> >     - uriparse library attempts that by providing default port and 
> > default hostname for certain schemes, but that can be made available 
> > as a patch to urlparse rather than new library. The need for such a 
> > change in urlparse needs to be analyzed, as there has not been any 
> > requirement raised as such for proving default port, default host for 
> > schemes whenever it is applicable.
> >   

Okay; It just seemed completist to provide said defaults.

> > 3) urlsplit, urlunsplit, spliting the authority into sub-components is
> > available in the current urlparse library itself and is RFC3986 
> > conformant.
> >   

Ah... it used to not do this for unknown schemes, which was my
original impetus for this.

> > 4) urljoin in the current urlparse ( patched with fixes) is currently 
> > RFC3986conformant.
> >
> > What urlparse further requires and this patch also lacks is ( as 
> > commented by John J Lee)
> > 1) Handling of IRIs.
> > 2) Python Unicode Strings.
> > 3) Percent- Encodings for IRIs and Python Unicode Strings.
> > ( There is a discussion going on on quote and unquote of unicode, and 
> > thatwould be basically be extended to above points as well)
> >
> > - If required, we can adopt the default host and port provision 
> > mechanisms as  mentioned in this patch to the current urlparse. 
> >
> > Other that that, I see that urlparse currently has all changes as 
> > mentioned inthis patch and makes the attached patch an obsolete one.
> >
> > Please let me know your comments/ thoughts.
> >   

It seems that urlparse now works for the case that caused me to rewrite
this (see the first comment on this bug for a link to the python-dev 
archives
where I posted about the 'itch' this code 'scratched'), so it's fine 
with me if
it just goes away now.

----------

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

From report at bugs.python.org  Sun Oct  4 01:04:04 2009
From: report at bugs.python.org (Arc Riley)
Date: Sat, 03 Oct 2009 23:04:04 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254611044.42.0.753938429452.issue7045@psf.upfronthosting.co.za>


Arc Riley <arcriley at gmail.com> added the comment:

Amaury, you are absolutely correct, \ud801 is not a valid unicode glyph,
however I am not giving Python \ud801, I am giving Python '?' (==
'\U00010451').

I am attaching a different short example that demonstrates that Python
is mishandling UTF-8 on both the interactive terminal and in scripts, u.py

The output should be the same, but on Python 3.1.1 compiled for wide
unicode it reports two different values.  As someone on #python-dev
found '?'.encode('utf-16').decode('utf-16') outputs the correct value.

----------
Added file: http://bugs.python.org/file15032/u.py

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

From report at bugs.python.org  Sun Oct  4 01:37:59 2009
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 03 Oct 2009 23:37:59 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254613079.47.0.439480447239.issue7045@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

I believe this is a duplicate of issue #3297.  When given a high unicode
scalar value directly in the source (rather than in escaped form) python
will split it into surrogates, even on a UTF-32 build where those
surrogates are nonsensical and ill-formed.

Patches for Issue #3672 probably made this more visible.

----------
nosy: +Rhamphoryncus

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

From report at bugs.python.org  Sun Oct  4 01:52:57 2009
From: report at bugs.python.org (Arc Riley)
Date: Sat, 03 Oct 2009 23:52:57 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1254613977.64.0.138902630689.issue7045@psf.upfronthosting.co.za>


Arc Riley <arcriley at gmail.com> added the comment:

This behavior is identical whether u.py or u.pyc is run on my systems,
where that previous ticket concerns differing behavior.

Though it is obviously related.

----------
versions:  -Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun Oct  4 02:09:28 2009
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 04 Oct 2009 00:09:28 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1254614968.56.0.957346980958.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Looks like the failure mode has changed here, presumably due to issue
#3672 patches.  It now always fails, even after loading from a .pyc. 
This is using py3k via bzr, which reports itself as 3.2a0

$ rm unicodetest.pyc 
$ ./python -c 'import unicodetest'
Result: False
Len: 2 1
Repr: '\ud800\udd23' '\U00010123'
[28877 refs]
$ ./python -c 'import unicodetest'
Result: False
Len: 2 1
Repr: '\ud800\udd23' '\U00010123'
[28708 refs]

----------
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct  4 02:42:53 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Sun, 04 Oct 2009 00:42:53 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1254616973.48.0.692666847629.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Jesse: this is ready for your review now.  Thanks,

Charles

----------

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

From report at bugs.python.org  Sun Oct  4 07:44:05 2009
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 04 Oct 2009 05:44:05 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1254635045.77.0.589610642174.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

I've traced down the biggest problem to decode_unicode in ast.c.  It
needs to convert everything into a form of escapes so it becomes pure
ascii, which then become evaluated back into a unicode object. 
Unfortunately, it uses UTF-16-BE to do so, which always split
surrogates.  Switching it to UTF-32-BE is fairly straightforward, and
works even on UTF-16 (or "narrow") builds.

Incidentally, there's no point using the surrogatepass error handler
once we actually support surrogates.

Unfortunately there's a second problem in repr(). 
'\U0001010F'.isprintable() returns True on UTF-32 builds and False on
UTF-16 builds.  This causes repr() to escape it unnecessarily on UTF-16
builds.  repr() at least joins surrogate pairs before its internally
printable test (unlike .isprintable() or any other str method), but it
turns out all of the APIs in unicodectype.c only accept a single 16-bit
int in UTF-16 builds anyway.  That'll be a bigger patch than the first part.

----------

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

From report at bugs.python.org  Sun Oct  4 08:41:48 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 04 Oct 2009 06:41:48 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1254638508.97.0.253786706566.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Ok, changed to "note" directives instead of "warning"s. Anything else
that keeps this from being applied?

----------
Added file: http://bugs.python.org/file15033/subprocess.rst.patch

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

From report at bugs.python.org  Sun Oct  4 08:48:18 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 04 Oct 2009 06:48:18 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1254638898.81.0.525942203455.issue6760@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14817/subprocess.rst.patch

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

From report at bugs.python.org  Sun Oct  4 09:20:49 2009
From: report at bugs.python.org (Valery)
Date: Sun, 04 Oct 2009 07:20:49 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>


New submission from Valery <khamenya at gmail.com>:

Hi all

(I never filed a bug, so, I am not sure that all fields are OK)

Anyway, here is the self explaining issue: 

$ python 
Python 2.6.3 (r263:75183, Oct  3 2009, 11:20:50) 
[GCC 4.4.1] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> from logging import * 

Traceback (most recent call last): 
  File "<stdin>", line 1, in <module> 
AttributeError: 'module' object has no attribute 'NullHandler' 
$ uname -a 
Linux vaktop 2.6.31-11-generic #38-Ubuntu SMP Fri Oct 2 11:55:55 UTC 
2009 i686 GNU/Linux 

this issue blocks me badly :(

regards
--
Valery

----------
components: Library (Lib)
messages: 93520
nosy: vak
severity: normal
status: open
title: "from logging import *" causes an error under Ubuntu Karmic
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct  4 09:29:03 2009
From: report at bugs.python.org (Valery)
Date: Sun, 04 Oct 2009 07:29:03 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254641343.3.0.615373073899.issue7052@psf.upfronthosting.co.za>


Valery <khamenya at gmail.com> added the comment:

I have just installed python2.5 in addition. 
And there is no this issue with it.
So, it rather speific to python2.6

----------

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

From report at bugs.python.org  Sun Oct  4 09:56:01 2009
From: report at bugs.python.org (Mattelaer)
Date: Sun, 04 Oct 2009 07:56:01 +0000
Subject: [issue7053] wrong overload of slot wrapper
In-Reply-To: <1254642961.53.0.52904342444.issue7053@psf.upfronthosting.co.za>
Message-ID: <1254642961.53.0.52904342444.issue7053@psf.upfronthosting.co.za>


New submission from Mattelaer <olivier.mattelaer at uclouvain.be>:

wrong redirection of slot wrapper:

class.__iter__=list.__iter__
doesn't work. (the __iter__ still refer to the one define in class)

The file in attachment shows an example of this problem

----------
components: None
files: test.py
messages: 93522
nosy: omatt
severity: normal
status: open
title: wrong overload of slot wrapper
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15034/test.py

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

From report at bugs.python.org  Sun Oct  4 10:29:22 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sun, 04 Oct 2009 08:29:22 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254644962.53.0.0726558619705.issue7052@psf.upfronthosting.co.za>


Ryan Leslie <rylesny at gmail.com> added the comment:

Looks like a merge has gone bad. NullHandler has existed for a while on
trunk but is not present in the 2.6.3 tag (__all__ was updated to
include it, however):

/python/tags/r263/Lib/logging/__init__.py

----------
nosy: +ryles

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

From report at bugs.python.org  Sun Oct  4 10:57:02 2009
From: report at bugs.python.org (Trundle)
Date: Sun, 04 Oct 2009 08:57:02 +0000
Subject: [issue7053] wrong overload of slot wrapper
In-Reply-To: <1254642961.53.0.52904342444.issue7053@psf.upfronthosting.co.za>
Message-ID: <1254646622.82.0.899960860781.issue7053@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

This is defined behaviour and no bug at all. Special methods are looked
up in the type for new-style classes and not in the instance. Try
changing ``self.__iter__=self.__str__`` to ``test1.__iter__ =
self.__str__`` in your example (which will then raise a TypeError on
the second iteration).

----------
nosy: +Trundle

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

From report at bugs.python.org  Sun Oct  4 11:00:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Oct 2009 09:00:08 +0000
Subject: [issue7053] wrong overload of slot wrapper
In-Reply-To: <1254642961.53.0.52904342444.issue7053@psf.upfronthosting.co.za>
Message-ID: <1254646808.94.0.204817839566.issue7053@psf.upfronthosting.co.za>


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

Closing as "won't fix".

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

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

From report at bugs.python.org  Sun Oct  4 11:34:56 2009
From: report at bugs.python.org (lekma)
Date: Sun, 04 Oct 2009 09:34:56 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254648896.08.0.268615848117.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

Even though I don't fully agree with your comments here is a second
attempt addressing them, against trunk.

For the record, I think that the signature difference is enough to
warrant a name that is a clear cut from PyErr_NewException.
And in the spirit of the Py_InitModule and PyModule_Create families of
function I thought the most common/simple form should stand out from the
more complete one.

But, hey, I'm happy if this gets in (in any form :).

----------
Added file: http://bugs.python.org/file15035/issue7033_trunk_2.diff

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

From report at bugs.python.org  Sun Oct  4 11:36:12 2009
From: report at bugs.python.org (lekma)
Date: Sun, 04 Oct 2009 09:36:12 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1254648972.61.0.689468213713.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

Same as previous against py3k

----------
Added file: http://bugs.python.org/file15036/issue7033_py3k_2.diff

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

From report at bugs.python.org  Sun Oct  4 11:41:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 09:41:17 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254649277.88.0.0533999761459.issue7049@psf.upfronthosting.co.za>


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

Shrug.  That doesn't really bother me.  x**y%z and pow(x, y, z) aren't 
going to match anyway, as soon as x**y has to be rounded.

What would bother me more is the idea of having, with precision 4:

pow(3, 22, 12347) -> nan
pow(3, 23, 12347) -> 7820
pow(3, 24, 12347) -> nan
pow(3, 25, 12347) -> 8645
pow(3, 26, 12347) -> 1241
etc.

(or a similar phenomenon with the 1st argument varying and 2nd and 3rd 
arguments fixed).  Or something that called pow(x, 3, 100003) with 
precision 5, and worked for all but 3 possible values of x.  That sort 
of thing is the cause of hidden bugs.

It's all academic really;  no-one's going to use Decimal's 3-argument 
pow.  I'm not really sure why it's supported at all.  Come to that, I 
don't really understand why Python's 3-argument pow belongs in the core 
interpreter (as opposed to somewhere in the standard library).  If it 
hadn't been there, and if __pow__ didn't accept a third argument, I 
suspect no-one would have tried to implement 3-argument pow for Decimal.

----------

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

From report at bugs.python.org  Sun Oct  4 11:49:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 09:49:25 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254649765.51.0.678441476462.issue7052@psf.upfronthosting.co.za>


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


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
priority:  -> critical
stage:  -> needs patch
type: resource usage -> behavior

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

From report at bugs.python.org  Sun Oct  4 12:27:51 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Sun, 04 Oct 2009 10:27:51 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254652071.23.0.932265710711.issue7052@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

The same True for captureWarnings? (It's also is only present in __all__)

----------
nosy: +gregorlingl

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

From report at bugs.python.org  Sun Oct  4 12:31:50 2009
From: report at bugs.python.org (Mark Schlieker)
Date: Sun, 04 Oct 2009 10:31:50 +0000
Subject: [issue7054] Python25.chm seems to be broken
In-Reply-To: <1254652310.61.0.423717253286.issue7054@psf.upfronthosting.co.za>
Message-ID: <1254652310.61.0.423717253286.issue7054@psf.upfronthosting.co.za>


New submission from Mark Schlieker <Sternenfaenger77 at googlemail.com>:

CHM file for Python 2.5 documentation does not work when being used
without Python installation.

My OS is: Microsoft Windows XP (sp2)

Steps on how to reproduce:

prerequisite:
1) No python has been installed on machine (not sure if necessary)

steps:
1) Download Python25.chm from
http://www.python.org/download/releases/2.5.2/ (md5 digest:
4c2f7e124287525a93849b0b53893bf0)
2) Open file Python25.chm by double clicking on it using file explorer.

noticed behaviour ==> 

Help window opens with navigation pane (on the left) showing index but
on the right window pane there is only a text saying that navigation to
website has been cancelled. When clicking on any item in the navigation
pane still no other text gets displayed on the right window pane else
than "Navigation to website has been cancelled".

expected behaviour ==>

Help window shows documentation in the right hand side window pane.

----------
assignee: georg.brandl
components: Documentation
messages: 93530
nosy: Mark77, georg.brandl
severity: normal
status: open
title: Python25.chm seems to be broken
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Oct  4 12:58:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 10:58:46 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254653926.03.0.570695484839.issue7052@psf.upfronthosting.co.za>


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

Georg committed a fix but now we have:

>>> from logging import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'captureWarnings'

----------
nosy: +georg.brandl, pitrou

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

From report at bugs.python.org  Sun Oct  4 13:03:52 2009
From: report at bugs.python.org (Jan Hosang)
Date: Sun, 04 Oct 2009 11:03:52 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254654232.28.0.6325407397.issue5395@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

Ezio, I moved the test to a separate method. Also I couldn't find 
something to close the file if I don't care about errors. I thought an 
assertRises would be wrong, as I am not debugging files here, so I added a 
function to call a callable I expect to throw an exception (you said you 
don't like the try/close/except/pass). I don't know if it is okay to add 
functions to test_support, though.

----------
Added file: http://bugs.python.org/file15037/array_ioerror.patch

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

From report at bugs.python.org  Sun Oct  4 13:06:33 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Sun, 04 Oct 2009 11:06:33 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254654393.36.0.943300788618.issue7052@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

As stated above: the name

captureWarnings

is also present *only* in __all__. Same reason, same effect.

----------

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

From report at bugs.python.org  Sun Oct  4 13:17:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 11:17:45 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254655065.36.0.188064571907.issue5395@psf.upfronthosting.co.za>


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

There doesn't seem to be any reason to introduce the
"expect_exception()" helper, rather than to use a with statement. Am I
mistaken?

----------
nosy: +pitrou
stage: test needed -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Sun Oct  4 13:19:09 2009
From: report at bugs.python.org (Mark Schlieker)
Date: Sun, 04 Oct 2009 11:19:09 +0000
Subject: [issue7054] Python25.chm seems to be broken
In-Reply-To: <1254652310.61.0.423717253286.issue7054@psf.upfronthosting.co.za>
Message-ID: <1254655149.03.0.305250641792.issue7054@psf.upfronthosting.co.za>


Mark Schlieker <Sternenfaenger77 at googlemail.com> added the comment:

Oh I found out myself: the file is ok. When the message gets displayed
it has to do with security settings in Windows XP:

Solution:

Right click on the file in file explorer and choose properties in order
to open the properties dialog.
Click on "allow" under security.

----------

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

From report at bugs.python.org  Sun Oct  4 13:19:26 2009
From: report at bugs.python.org (Mark Schlieker)
Date: Sun, 04 Oct 2009 11:19:26 +0000
Subject: [issue7054] Python25.chm seems to be broken
In-Reply-To: <1254652310.61.0.423717253286.issue7054@psf.upfronthosting.co.za>
Message-ID: <1254655166.37.0.251025105066.issue7054@psf.upfronthosting.co.za>


Changes by Mark Schlieker <Sternenfaenger77 at googlemail.com>:


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

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

From report at bugs.python.org  Sun Oct  4 13:21:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 11:21:29 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254655289.52.0.849755463103.issue5395@psf.upfronthosting.co.za>


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

Ok, I get it, you want f.close() to always succeed, even if the
underlying file descriptor has already been closed.
Well, I so no reason to introduce a helper anyway, the following four
lines are much more readable and explicit:

    try:
        f.close()
    except IOError:
        pass

----------

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

From report at bugs.python.org  Sun Oct  4 14:25:10 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 04 Oct 2009 12:25:10 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254659110.26.0.826700623496.issue7052@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Not quite sure what happened, yet. It may be, as Ryan said, that a merge
went wrong somewhere. I've altered Lib/logging/__init__.py in
release26-maint to remove captureWarnings from __all__.

Note that the change which introduced captureWarnings and NullHandler
was added on 03 Dec 2008 in r67511.

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

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

From report at bugs.python.org  Sun Oct  4 14:43:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 12:43:32 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254660212.05.0.533173459281.issue7042@psf.upfronthosting.co.za>


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

I'm seeing this failure too, on a 64-bit build of the trunk on OS X 
10.6.1.

If I understand the test, it's setting up a timer that's supposed to run 
for 0.3 seconds of 'virtual time', signal, and then signal every 0.2 
seconds of virtual time thereafter.  The test passes after 4 (or is it 3?) 
signals have been handled, for a total of 0.9 seconds of virtual time.

The problem appears to be that the 'for i in xrange(100000000): ...' loop 
simply isn't long enough for 0.9 seconds of virtual time to even elapse:  
on my machine, around 0.06 seconds of virtual time appear to have elapsed 
by the time the loop is finished.

When I increase the loop to 'for i in xrange(10**10): ...', the test 
*eventually* passes.  Those 0.9 seconds of virtual time took over 29 
minutes of real time, on an otherwise mostly-idle machine.  (2.53GHz Core 
2 Duo.)

When I add some actual work into the xrange loop (computing pow(12345, 
67890, 10000001) and throwing away the result) then test_itimer_virtual 
passes, in a reasonably short amount of time (a second or so).

I don't know what the precise definition of virtual time is, or whether 
there's a defect in the way that Snow Leopard is measuring it.  At any 
rate, I don't think the reported behaviour is a bug in the signal module:  
the test should be fixed somehow, though (perhaps by adding that pow() 
call).

----------
nosy: +mark.dickinson
versions: +Python 2.7

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

From report at bugs.python.org  Sun Oct  4 15:01:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 13:01:20 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254661280.24.0.779843477643.issue7042@psf.upfronthosting.co.za>


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

Issue #5972 looks like the same problem.

----------

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

From report at bugs.python.org  Sun Oct  4 15:03:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 13:03:14 +0000
Subject: [issue5972] Failing test_signal.py on Redhat 4.1.2-44
In-Reply-To: <1241817614.78.0.115572621899.issue5972@psf.upfronthosting.co.za>
Message-ID: <1254661394.38.0.100375550615.issue5972@psf.upfronthosting.co.za>


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

See also issue #7042.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sun Oct  4 15:08:34 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 04 Oct 2009 13:08:34 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254661714.7.0.635831704064.issue7052@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Noticed that the code in the r262 tag (dated 13 Mar 2009) seems OK. I
don't know how to find out how this happened, i.e. is it something I did
wrong or is it something which went wrong during the release process?
Any pointers gratefully received.

----------

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

From report at bugs.python.org  Sun Oct  4 15:08:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 13:08:53 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254661733.19.0.570183141813.issue7042@psf.upfronthosting.co.za>


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

This may also explain why the x86 FreeBSD trunk buildbot is currently 
hanging on test_signal.

(And I see Ned already mentioned issue 5972 above.  Sorry for the noise.)

----------

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

From report at bugs.python.org  Sun Oct  4 15:23:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 13:23:03 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254662583.88.0.0446795756927.issue7042@psf.upfronthosting.co.za>


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

chuck: does the attached patch fix the problem for you?

----------
keywords: +patch
Added file: http://bugs.python.org/file15038/issue7042.patch

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

From report at bugs.python.org  Sun Oct  4 16:24:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Oct 2009 14:24:45 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254666285.16.0.225644352518.issue5395@psf.upfronthosting.co.za>


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

I tried to apply both the patches on the trunk but the tests don't pass.
With the latest patch I get an EOFError instead of IOError in the
assertRaises.

The function I was talking about was test_support.unlink(), but that
just removes the file, it doesn't close it, so the try/except is fine
when you close it (I also see that you already added
test_support.unlink() in the new patch).
I agree with Antoine that the helper function is not necessary.


A few more comments about the latest patch:
1) the try/except that imports the os module seems unnecessary to me;
2) if there are really cases where os is not available, the test should
be skipped with a message that says that the os module is not available
and that the test cannot be executed (with return the test is marked as
'passed' even if nothing is actually tested);
3) if os.close(f.fileno()) is required instead of a simpler f.close()
please write a short comment to clarify why;
4) if there are cases where EOFError is raised and they are not tested,
it would be nice to add another test that checks if/when EOFError is raised.

----------

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

From report at bugs.python.org  Sun Oct  4 17:10:39 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 04 Oct 2009 15:10:39 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254669039.68.0.36921901679.issue7052@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Ok, found it. It looks like I messed up in r72005 when fixing #5854.
Very sorry to all for the inconvenience. I will add a unit test to try
and catch this in the future.

----------

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

From report at bugs.python.org  Sun Oct  4 17:17:12 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 04 Oct 2009 15:17:12 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254669432.38.0.985513926776.issue7052@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I see Benjamin's beaten me to it - thanks, Benjamin.

----------

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

From report at bugs.python.org  Sun Oct  4 18:11:44 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Oct 2009 16:11:44 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254672704.52.0.47137672123.issue7052@psf.upfronthosting.co.za>


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

I've already added logging to test___all__.py which checks the __all__
attribute.

----------

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

From report at bugs.python.org  Sun Oct  4 18:45:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 16:45:11 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>


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

This patch replaces the explicit list of modules in test___all__ with an
automatic detection of modules having a __all__ attribute, so that we
don't forget any. It doesn't really appear to slow things down;
test___all__ only takes one second here.

----------
components: Library (Lib), Tests
messages: 93548
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Automatic test___all__
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct  4 18:45:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 16:45:33 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254674733.8.0.242796970694.issue7055@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file15039/test_all.patch

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

From report at bugs.python.org  Sun Oct  4 19:17:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Oct 2009 17:17:18 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254676638.57.0.081768581999.issue7055@psf.upfronthosting.co.za>


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

Hey, I was doing that too! :)

----------

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

From report at bugs.python.org  Sun Oct  4 19:25:14 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 04 Oct 2009 17:25:14 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254672704.52.0.47137672123.issue7052@psf.upfronthosting.co.za>
Message-ID: <774553.27429.qm@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Georg Brandl  added the comment:

> I've already added logging to test___all__.py which checks the __all__
> attribute.

Sorry, I thought Benjamin did that.

Thanks and regards,

Vinay Sajip

----------

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

From report at bugs.python.org  Sun Oct  4 19:39:26 2009
From: report at bugs.python.org (Preston Landers)
Date: Sun, 04 Oct 2009 17:39:26 +0000
Subject: [issue1378] fromfd() and dup() for _socket on WIndows
In-Reply-To: <1194103455.44.0.390687208828.issue1378@psf.upfronthosting.co.za>
Message-ID: <1254677966.86.0.564825577539.issue1378@psf.upfronthosting.co.za>


Preston Landers <planders at gmail.com> added the comment:

I'm curious what happened with this issue.  It says closed+accepted but
it doesn't appear to be checked in.  Was there a fatal problem
implementing this feature on Windows?   Is it hung up on the inability
to dup SSL sockets?  

I'm highly interested in deploying Python web servers using FastCGI,
SCGI, WSGI, etc on the Windows server platform.  I wrote a simple
Windows fromfd() patch for Python 2.1 which was successfully used by my
organization for many years.  Now we are trying to move to a newer
version of Python and still facing the need to patch this in.  Just
wondering what happened with this feature and perhaps there is something
I can do to help move it along again.  Many Python projects like flup,
python-scgi, etc would be able to support Windows via this feature.

(PS if this question is more appropriately raised on a mailing list
rather than the issue tracker, I apologize in advance.)

----------
nosy: +planders

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

From report at bugs.python.org  Sun Oct  4 19:46:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 17:46:38 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254678398.52.0.269232211835.issue7055@psf.upfronthosting.co.za>


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

There was a problem with os.environ (from distutils and CGIHTTPServer)
changes disturbing test_wsgiref, so I've added an unconditional
save/restore of os.environ in test.regrtest.

----------
Added file: http://bugs.python.org/file15040/test_all.patch

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

From report at bugs.python.org  Sun Oct  4 19:47:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 17:47:51 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254678471.84.0.62651906514.issue7055@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15039/test_all.patch

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

From report at bugs.python.org  Sun Oct  4 20:49:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Oct 2009 18:49:15 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254682155.85.0.572339204689.issue7042@psf.upfronthosting.co.za>


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

I've applied the above patch in r75236 (trunk), r75237 (release26-maint),
r75238 (py3k) and r75239 (release31-maint).  With any luck this should fix 
the issue.  Jan Hosang, can you confirm that this is fixed?

----------
resolution:  -> fixed
status: open -> pending
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct  4 21:16:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 19:16:22 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254683782.03.0.576667685468.issue7055@psf.upfronthosting.co.za>


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

For os.environ, wouldn't it be better to fix the tests so that they
don't disturb the environment?  Even if the CGIHTTPServer legitimately
modifies the environment, shouldn't it be the responsibility of its test
suite to wrap it so that the environment isn't modified when the tests
are done?

What _would_ be good, IMO, would be if regrtest would check for
modifications and complain.  Then we wouldn't have to wait until another
test was impacted by the bad test to catch it.

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

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

From report at bugs.python.org  Sun Oct  4 21:19:58 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 04 Oct 2009 19:19:58 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <1254316550.16.0.817669715381.issue6992@psf.upfronthosting.co.za>
Message-ID: <4AC8F559.5070201@egenix.com>


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

Tarek Ziad? wrote:
> 
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
>> I'm just suggesting to add the meta-data field in order to recreate
>> consistency - not advocating that setup() parameter or its use.
> 
> Yes but fixing this inconsitency can be done on either side:
> A - remove the maintainer and maintainer_email 
> B - add the Maintainer and Maintainer-email in the metadata
> 
> While I understand your PoV about the fact that B/ is not impacting
> existing packages and doesn't require any deprecation, I would like to
> find some use cases for having such fields in the Metadata, other than
> fixing the inconsistency.
> 
> If we don't have a use case, I'd go for A/

Having a maintainer for a package is not at all uncommon.

Whether you put that maintainer into a separate field or not
is really a mix of respect/taste/culture.

I'd go for B, since we already have the maintainer setup()
variable and just need to add the missing meta-data field.

Whether this gets used or not is up to 3rd party code
using the meta-data to decide and not really a distutils
question.

----------

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

From report at bugs.python.org  Sun Oct  4 21:38:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Oct 2009 19:38:36 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254683782.03.0.576667685468.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254685334.5580.4.camel@localhost>


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

You are right, such an approach would be better. I don't really want to
mess with test_distutils, however, and I was looking for a reliable fix
to the problem.

----------

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

From report at bugs.python.org  Sun Oct  4 21:41:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 19:41:50 +0000
Subject: [issue7056] regrtest runtest_inner calls findtestdir unnecessarily
In-Reply-To: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>
Message-ID: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Running regrtest over an installed, read-only Lib produces several test
failures, and regrtest crashes.  In investigating these, which I will
deal with in other issues, I found that the regrtest runtest_inner
method takes a 'testdir' argument, and if it is none calls
'findtestdir'.  findtestdir uses __file__ or arg[0] to compute the
directory in which regrtest is located, something that does not change
during the lifetime of a given regrtest run, so at best these repeated
calls are redundant.  At worst, it triggered the regrtest abort because
the value of arg[0] was changed by one of the tests.

As it turns out, the testdir argument is never actually referenced in
the body of runtest_inner.  runtest_inner in turn is called only by
runtest, which uses _its_ testdir argument only in the call to
runtest_inner.

Attached are two patches.  The first just removes testdir from
runtest_inner, the second removes it from runtest as well.  On my Gentoo
linux box the full (-uall) test suite passes with either patch applied.
 (With the exception of test_ttk_guionly, which failed before the patch
at as well.)

----------
components: Tests
files: remove_testdir_from_runtest_inner.patch
keywords: patch
messages: 93557
nosy: r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: regrtest runtest_inner calls findtestdir unnecessarily
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15041/remove_testdir_from_runtest_inner.patch

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

From report at bugs.python.org  Sun Oct  4 21:42:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 19:42:28 +0000
Subject: [issue7056] regrtest runtest_inner calls findtestdir unnecessarily
In-Reply-To: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>
Message-ID: <1254685348.81.0.792793016627.issue7056@psf.upfronthosting.co.za>


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

second patch

----------
Added file: http://bugs.python.org/file15042/remove_testdir_from_runtest.patch

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

From report at bugs.python.org  Sun Oct  4 22:02:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 20:02:46 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1254686566.58.0.631226957292.issue7055@psf.upfronthosting.co.za>


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

Hmm.  Maybe we could fix it _and_ complain.

----------

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

From report at bugs.python.org  Sun Oct  4 22:39:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 04 Oct 2009 20:39:26 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1254688766.5.0.916911710627.issue3297@psf.upfronthosting.co.za>


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

This last point is already tracked by issue5127.

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

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

From report at bugs.python.org  Sun Oct  4 22:58:37 2009
From: report at bugs.python.org (Andrew Straw)
Date: Sun, 04 Oct 2009 20:58:37 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1254689917.17.0.225162459712.issue1054967@psf.upfronthosting.co.za>


Andrew Straw <astraw at users.sourceforge.net> added the comment:

stdeb ( http://github.com/astraw/stdeb ) now includes a bdist_deb
distutils command.

----------

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

From report at bugs.python.org  Sun Oct  4 23:46:59 2009
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 04 Oct 2009 21:46:59 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254692819.07.0.257919015869.issue5127@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Surrogates aren't optional features of UTF-16, we really need to get
this fixed.  That includes .isalpha().

We might keep the old public API for compatibility, but it should be
clearly marked as broken for non-BMP scalar values.

I don't see a problem with changing 2.x.  The existing behaviour is
broken for non-BMP scalar values, so surely nobody can claim dependence
on it.

----------
nosy: +Rhamphoryncus
type:  -> behavior

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

From report at bugs.python.org  Mon Oct  5 00:48:18 2009
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 04 Oct 2009 22:48:18 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1254696498.89.0.700073125678.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Patch, which uses UTF-32-BE as indicated in my last comment.  Test included.

----------
keywords: +patch
Added file: http://bugs.python.org/file15043/py3k-nonBMP-literal.diff

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

From report at bugs.python.org  Mon Oct  5 00:59:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Oct 2009 22:59:28 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>


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

The transition from Tkinter/tkinter to tkinter/_tkinker in 3.x docs is
incomplete.

1. There are several places not in titles or beginning of sentences
where Tkinter (roman type) needs to be replaced with tkinter (fixed
type, as elsewhere).

2. "24.1.1. Tkinter Modules
Most of the time, the tkinter is all" <<delete 'the' before tkinter>>

24.1.6.4. Coupling Widget Variables
 "from a class called Variable, defined in the tkinter." ditto

3. 24.1.5. How Tk and Tkinter are Related
"tkinter (C) 
These commands and their arguments will be passed to a C function in the
tkinter - note the lowercase - extension module"
Change 'tkinter' to '_tkinter' and 'lowercase' to 'underscore'.

"Xlib (C) 
the Xlib library to draw graphics on the screen. "

Is this still true? Or does Tk now use native libraries?

Not 3.x specific.

10. "Specifically, the man pages in the mann directory are most useful."
Is 'mann' literally correct? a typo? or meant to mean 'man#', where # is
a digit? If the last, either man# or mann with the last 'n' a different
font would be clearer to me.

This is, of course, *nix specific.

11. "Credits:
Tkinter was written by Steen Lumholt and Guido van Rossum. 
Tk was written by John Ousterhout while at Berkeley. "
Except for the first two lines, the entries are in historical order, so
I would reverse the first two.
 
12. 24.1.6.6. Tk Option Data Types
"To specify an X bitmap filename, give the full path to the file,
preceded with an @, as in "@/usr/contrib/bitmap/gumby.bit"."
*nix only? what about windows .bmp file?

13. (ttk section) 24.2.3.1. Standard Options
"0, 1 or an empty is return." => "0, 1 or an empty string is returned."


PS. I like the colors of the option-description tables.

----------
assignee: georg.brandl
components: Documentation
messages: 93564
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: tkinter doc: more 3.x updates
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Oct  5 01:02:55 2009
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 04 Oct 2009 23:02:55 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1254697375.04.0.246013168216.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

With some further prodding I've noticed that although the test behaves
as expected in the py3k branch (fails on UTF-32 builds before the
patch), it doesn't fail using python 3.0.  I'm guessing there's
interactions with compile() vs import and the issue 3672 fix.  Still
good enough though, IMO.

----------

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

From report at bugs.python.org  Mon Oct  5 01:08:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2009 23:08:34 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

One of the failures when regrtest is run with a read-only Lib results
from test_runpy modifying sys.argv.  Antoine also found cases where
tests modified os.environ in issue 7055.  It seems useful to have
regrtest fix these kinds of environment corruptions when it can, but to
also issue warnings so that the tests in questions can be fixed.  In
some cases the warnings might also reveal bugs in the code being tested,
if the code being tested does a modification it should not be doing.

Attached is a patch that adds save/restore for os.environ and sys.argv,
with warning messages.

----------
components: Tests
files: regrtest_guards.patch
keywords: patch
messages: 93566
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add some test execution environment protection to regrtest
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15044/regrtest_guards.patch

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

From report at bugs.python.org  Mon Oct  5 01:19:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Oct 2009 23:19:49 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1254698389.08.0.226615249856.issue7057@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Mon Oct  5 02:05:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2009 00:05:34 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254701134.68.0.733164833826.issue7058@psf.upfronthosting.co.za>


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

Or should regrtest convert these into test failures for reporting purposes?

----------

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

From report at bugs.python.org  Mon Oct  5 02:52:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Oct 2009 00:52:01 +0000
Subject: [issue7059] 'checking getaddrinfo bug' doesn't output the result
	during ./configure
In-Reply-To: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>
Message-ID: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>


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

This is what I see while running ./configure on both trunk and py3k, on
Linux:
checking for major... yes
checking for getaddrinfo... yes
checking getaddrinfo bug... checking for getnameinfo... yes
checking whether time.h and sys/time.h may both be included... yes

the yes/no after 'checking getaddrinfo bug...' is missing.
FWIW that bit of code is at the line 20225, but I couldn't figure out
how to fix it.

----------
components: Installation
messages: 93568
nosy: ezio.melotti
priority: low
severity: normal
status: open
title: 'checking getaddrinfo bug' doesn't output the result during ./configure
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Oct  5 03:00:24 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 05 Oct 2009 01:00:24 +0000
Subject: [issue7043] test_urllib: constructLocalFileUrl returns invalid URLs
	on Windows
In-Reply-To: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
Message-ID: <1254704424.15.0.766405627577.issue7043@psf.upfronthosting.co.za>


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

I think this can be fixed by merging r72343.

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

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

From report at bugs.python.org  Mon Oct  5 03:40:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2009 01:40:57 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

test_multiprocessing is producing tracebacks and hanging on py3k trunk.
 I think this started happening fairly recently, as it seemed to work in
one not-too-old checkout until I did an svn up and then it started
failing.  3.1 seems fine.  I've attached the tracebacks, including the
tracebacks I get when I ctrl-C to break the hang.  My system is Gentoo
Linux.

----------
assignee: jnoller
files: test_multiprocessing.log
messages: 93570
nosy: jnoller, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing dictionary changed size errors and hang
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file15045/test_multiprocessing.log

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

From report at bugs.python.org  Mon Oct  5 03:41:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2009 01:41:17 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1254706877.25.0.921532805523.issue7060@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Oct  5 04:14:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2009 02:14:55 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1254708895.42.0.784959462277.issue7060@psf.upfronthosting.co.za>


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

r75241 seems to be the cause.  Tests passes on r75240, but gives the
dict error and hang on r75241.

----------

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

From report at bugs.python.org  Mon Oct  5 06:14:32 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 05 Oct 2009 04:14:32 +0000
Subject: [issue7043] test_urllib: constructLocalFileUrl returns invalid URLs
	on Windows
In-Reply-To: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
Message-ID: <1254716072.98.0.971580829991.issue7043@psf.upfronthosting.co.za>


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

Fixed and Committed revision 75253.
Will just wait for windows buildbot to test it before closing.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Mon Oct  5 06:17:14 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 05 Oct 2009 04:17:14 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1254716234.19.0.662626100896.issue7026@psf.upfronthosting.co.za>


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

Committed revision 75254 for release26-maint.

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

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

From report at bugs.python.org  Mon Oct  5 06:34:36 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2009 04:34:36 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>


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

Reading through 24.5 on the turtle module, I have a number of comments
aimed at improvements. Some are straightforward fixes which any doc
maintainer could enter. Others are questions about meaning that I
presume the current maintainer, gregor lingl may have to answer. But he
is not an option of the Assigned To: pulldown list. These are introduced
by '??'. Quotes are from 3.1.1 docs.

24.5.1. Introduction

"version of python installed with Tk support.": cap 'python' to 'Python'

'which draws on ?the? Screen - instance': delete '-'

"To use multiple turtles an a screen ": an > on

"24.5.2. Overview over available Turtle and Screen methods":

'over' > 'of'

24.5.3.1. Turtle motion

?? distance units? pixel or world, depending on mode?
presume yes, but should say something here.

24.5.3.6. Using events

"turtle.onclick(fun, btn=1, add=None) 

It seems that 'add=False' would be same as 'add=None' and more
consistent with below.

"add ? True or False ? if True, a new binding will be added, otherwise
it will replace a former binding "

?? I do not understand what this means. Normal Python binding
(assignment) adds a new binding, replacing an old one if there was one.
How is turtle different? (And why should it be?)

"turtle.onrelease(fun, btn=1, add=None) "
"turtle.onrelease(fun, btn=1, add=None) "
 same pair of comments

24.5.3.8. Excursus about the use of compound shapes

'excursus' is so obscure that I have never seen/heard it before and had
to look it up to verify that it was an English word. The definitions I
found do not quite fit the usage. 'Compound shapes' is quite sufficient
for the section title. 

If change the title, there is also the reference to this section in
24.5.5. The public classes of the module turtle to be changed.


24.5.4. Methods of TurtleScreen/Screen and corresponding functions
"Most of the examples in this section refer to a TurtleScreen instance
called screen."

However, 
24.5.4.1. Window control
turtle.bgcolor(*args) "

and so on throughout the section.
??  I presume that should be 
"screen.bgcolor(*args)" and so on throughout the section.

.clear(), .reset()
"Note This TurtleScreen method is available as a global function only
under the name clearscreen. The global function clear is another one
derived from the Turtle method clear."

?? I presume 'another' means 'a different', but then I do not understand
the difference.

"turtle.delay(delay=None) 
Parameter: delay ? positive integer 

Set or return the drawing delay in milliseconds. (This is approximately
the time interval between two consecutive canvas updates.) The longer
the drawing delay, the slower the animation."

?? Unclear how this interacts with turtle.speed

"turtle.tracer(n=None, delay=None) 
Parameters: n ? nonnegative integer 
delay ? nonnegative integer 

Turn turtle animation on/off and set delay for update drawings. If n is
given, only each n-th regular screen update is really performed. (Can be
used to accelerate the drawing of complex graphics.) Second argument
sets delay value (see delay())."

?? does .tracer() (no args) turn animation off?

"Remark: in order to be able to register key-events, TurtleScreen must
have the focus. (See method listen().
>>> def f():
...     fd(50)
...     lt(60)
...
>>> screen.onkey(f, "Up")
>>> screen.listen()"

>From the Remark, I expected the two calls to be in the opposite order.
Ditto for .onkeypress()

24.5.4.4. Input methods

"turtle.numinput(title, prompt, default=None, minval=None, maxval=None) 
Parameters: title ? string 
prompt ? string 
default ? number (optional) 
prompt ? number (optional) 
prompt ? number (optional) "

Last two param names are 'minval' and 'maxval', not 'prompt'.

24.5.4.5. Settings and special methods

?? .mode: 'world' like standard or logo w/r/t angles?

"24.5.4.6. Methods specific to Screen, not inherited from TurtleScreen
turtle.exitonclick() 
Bind bye() method to mouse clicks on the Screen."

"If the value ?using_IDLE? in the configuration dictionary is False
(default value), also enter mainloop. Remark: If IDLE with the -n switch
(no subprocess) is used, this value should be set to True in turtle.cfg.
In this case IDLE?s own mainloop is active also for the client script."

>From Windows shortcut, I cannot tell how IDLE is started, but seems to
work. Anything need to be said re IDLE/turtle on windows?

My guess is that IDLE is running normally (without -n), so that there is
a subprocess, so that 'using_IDLE' is False even though I am using it,
just not in the same process.  Correct?

24.5.8. Changes since Python 2.6

Sections about 2.x changes should not be in 3.x docs.

----------
assignee: georg.brandl
components: Documentation
messages: 93574
nosy: georg.brandl, gregorlingl, tjreedy
severity: normal
status: open
title: Improve 24.5. turtle doc
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Oct  5 07:00:34 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 05 Oct 2009 05:00:34 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1254718834.51.0.913656582873.issue7061@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Thanks, Terry, for reading the docs that thoroughly.
Alas, for the next week I'm too busy (with preparing "Python f?r Kids"
for press) to work through this long list. 
Since it doesn't seem to be *very* urgent, I'll defer that work until
Oct. 12th or so. Then I'll be glad to discuss each and every point of
your list (some of them are known to me already) and I'm sure that the
necessary fixes and amendments can be done quickly then.
Best regards,
Gregor

----------

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

From report at bugs.python.org  Mon Oct  5 08:11:28 2009
From: report at bugs.python.org (Roman Sokolov)
Date: Mon, 05 Oct 2009 06:11:28 +0000
Subject: [issue7062] No docs for module 'IN'
In-Reply-To: <1254723088.53.0.157607422381.issue7062@psf.upfronthosting.co.za>
Message-ID: <1254723088.53.0.157607422381.issue7062@psf.upfronthosting.co.za>


New submission from Roman Sokolov <sokolov.r.v at gmail.com>:

Python 2.6.3 (r263:75183, Oct  2 2009, 11:22:08)
>>> import IN
>>> help(IN)

-- contain following lines:
"MODULE DOCS
    http://docs.python.org/library/IN"
, but server returns 404 error:
"The requested URL /library/IN was not found on this server."
and no docs found in source distribution:
$ cat ~/terrarium/sources/py26st/Doc/library/IN.rst
cat: /home/roma/terrarium/sources/py26st/Doc/library/IN.rst: No such 
file or directory

----------
assignee: georg.brandl
components: Documentation
messages: 93576
nosy: RSokolov, georg.brandl
severity: normal
status: open
title: No docs for module 'IN'
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  5 09:13:42 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 07:13:42 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254726822.89.0.0860970649875.issue5395@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

1&2) I removed the try/except around the import. I have no clue if os 
might be unavailable. Maybe leave out handling that until we see that 
breaking.

I added the try/except because I saw that in other tests in the same 
file when importing gc.

3) Done.
4) The EOFError exceptions are tested in test_tofromfile.

> I tried to apply both the patches on the trunk but the tests don't
> pass. With the latest patch I get an EOFError instead of IOError in
> the assertRaises.
That is the also behaviour before the patch, so the ferror(fp) does not 
fire. Either the test is inappropriate or your system doesn't regard 
reading a closed filehandle an error. I'm not able to investigate this 
as it works fine on my os x 10.6. What system did you test it on?

Reliable ways of producing IOErrors are harder to find than I thought. 
Deleting the file between to reads makes it just look truncated. Another 
method I tried was crashing a process which holds the other end of a 
pipe, but that's messy and complicated.

----------
Added file: http://bugs.python.org/file15046/array_ioerror.patch

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

From report at bugs.python.org  Mon Oct  5 09:23:01 2009
From: report at bugs.python.org (Harshad Modi)
Date: Mon, 05 Oct 2009 07:23:01 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254727381.62.0.414843943582.issue7024@psf.upfronthosting.co.za>


Harshad Modi <hmo at tinyerp.com> added the comment:

Hi, Antoine Pitrou!

It is missing key for ftp in url-handlers...
how can I add key for ftp?

Thanks

----------

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

From report at bugs.python.org  Mon Oct  5 09:23:52 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 07:23:52 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254727432.26.0.903347533653.issue7042@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I updated the checkout of the 26 branch, and the test runs fine now.

I have no clue about virtual time as well. If this is about passing time, 
there should be better ways (than those which break if your computer gets 
faster).

----------
status: pending -> open

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

From report at bugs.python.org  Mon Oct  5 09:33:39 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 07:33:39 +0000
Subject: [issue7038] test_curses fails on os x 10.6
In-Reply-To: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>
Message-ID: <1254728019.34.0.464619030403.issue7038@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I am not able to reproduce my own report :)

I'm sure I installed the 2.6.3 release, opened Terminal.app, checked 
`which python` and ran `python -m test.regrtest -uall`. I remember that I 
saw a crash report when I came back and some failed tests, so I ran the 
tests again (in a different tab) in verbose mode to post reports. (Maybe 
that makes sense to you.)

However, if I repeat what I did, the test does not fail anymore. So maybe 
just close it? :)

----------

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

From report at bugs.python.org  Mon Oct  5 10:12:29 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 08:12:29 +0000
Subject: [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>


New submission from Jan Hosang <jan.hosang at gmail.com>:

While I was backporting the new buffer API to 2.7 I noticed some issues 
in array_ass_slice() in Modules/arraymodule.c in the python 3k branch.

1) Manual memory reallocation had been replaced by calls to 
array_resize. But I think when PyMem_RESIZE is called the pointer to the 
memory might change. So this now happens in array_resize, and the
array->ob_item pointer changes but not it's local copy (item) in 
array_ass_slice().

2) The function moves too much memory if the array size is increased: 
(Py_SIZE(a)-d-ihigh) items should be moved, because Py_SIZE(a) was 
already modified by array_resize, but the function moves (Py_SIZE(a)-
ihigh) items.

While 1) might go unnoticed, 2) definitely broke slice tests in a 
"segmentation fault"-way (in debug mode forbidden bits show the error). 
I tried to write a test, but I don't know how to trigger 
array_ass_slice() with a write access, as it is not in array_as_sequence 
anymore (like in 2.7). How is slicing handled now?

----------
components: Library (Lib), Tests
messages: 93581
nosy: chuck
severity: normal
status: open
title: Memory errors in array.array
versions: Python 3.2

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

From report at bugs.python.org  Mon Oct  5 10:36:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Oct 2009 08:36:13 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254731773.14.0.16873031633.issue7042@psf.upfronthosting.co.za>


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

> If this is about passing time, there should be better ways (than
> those which break if your computer gets faster).

Agreed.  The challenge is to find ways that don't add too much in the
way of extra complexity, fragility, or dependencies to the unit test.

How about replacing the xrange(100000000) loop with something like this,
which allows 30 seconds of real time and then fails with a timeout 
message:

start_time = time.time()
while time.time() - start_time < 5.0:
    <use some process time here>
    if signal.getitimer(self.itimer) == (0.0, 0.0):
        break
else:
    self.fail('timeout waiting for virtual timer signal')

----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Mon Oct  5 10:37:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Oct 2009 08:37:13 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254731833.94.0.469000477176.issue7042@psf.upfronthosting.co.za>


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

Oops.  That 5.0 should have been 30.0, of course.

----------

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

From report at bugs.python.org  Mon Oct  5 11:01:34 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 09:01:34 +0000
Subject: [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1254733294.07.0.416222214153.issue7063@psf.upfronthosting.co.za>


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

The array type also defines tp_as_mapping->mp_ass_subscript, which has
priority in PyObject_SetItem().
A way to call array_ass_slice() is to use PySequence_SetItem(), but this
is hard to trigger from python code (it should be possible with ctypes).

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

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

From report at bugs.python.org  Mon Oct  5 11:03:09 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 09:03:09 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1254692819.07.0.257919015869.issue5127@psf.upfronthosting.co.za>
Message-ID: <4AC9B649.7040308@egenix.com>


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

Adam Olsen wrote:
> 
> Adam Olsen <rhamph at gmail.com> added the comment:
> 
> Surrogates aren't optional features of UTF-16, we really need to get
> this fixed.  That includes .isalpha().

We use UCS2 on narrow Python builds, not UTF-16.

> We might keep the old public API for compatibility, but it should be
> clearly marked as broken for non-BMP scalar values.

That has always been the case. UCS2 doesn't support surrogates.

However, we have been slowly moving into the direction of making
the UCS2 storage appear like UTF-16 to the Python programmer.

This process is not yet complete and will likely never complete
since it must still be possible to create things line lone
surrogates for processing purposes, so care has to be taken
when using non-BMP code points on narrow builds.

> I don't see a problem with changing 2.x.  The existing behaviour is
> broken for non-BMP scalar values, so surely nobody can claim dependence
> on it.

No, but changing the APIs from 16-bit integers to 32-bit integers
does require a recompile of all code using it. Otherwise you
end up with segfaults.

Also, the Unicode type database itself uses Py_UNICODE, so
case mapping would fail for non-BMP code points.

So if we want to support accessing non-BMP type information
on narrow builds, we'd need to change the complete
Unicode type database API to work with UCS4 code points and then
provide a backwards compatible C API using Py_UNICODE. Due
to the UCS2/UCS4 API renaming done in unicodeobject.h, this
would amount to exposing both the UCS2 and the UCS4 variants
of the APIs on narrow builds.

With such an approach we'd not break the binary API and
still get the full UCS4 range of code points in the type
database. The change would be possible in Python 2.x and
3.x (which now both use the same strategy w/r to change
management).

Would someone be willing to work on this ?

----------

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

From report at bugs.python.org  Mon Oct  5 11:48:20 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 05 Oct 2009 09:48:20 +0000
Subject: [issue7024] webbrowser : Could not open ftp server using
	webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254736100.64.0.371523914974.issue7024@psf.upfronthosting.co.za>


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

This bug is bit a tricky case.

Harshad: You might try the "work-around" suggested by Antoine. But that
is just a work-around. not a fix. Add an entry to gconf-editor like any
other. ( google).

The actual bug seems to be with gnome-open which is unable to handle ftp
urls.

$ gnome-open http://www.google.com
02:44 PM:senthil@:~/python/trunk/Lib
$ gnome-open ftp://ftp.freebsd.org
Error showing url: The specified location is not mounted

Google for (gnome-open + bug + ftp) you will be given the list of bugs.

In my case, I think the user-installed firefox has taken the control of
the ftp mimetype and in your case, gnome-open is the default and it is
failing with ftp.

As per suggestion just work-around it with ftp handlers and it should
do. May check with ubuntuforums for suggestions too.

There is a no problem with the webbrowser.py and I am closing this bug
as Invalid.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 11:59:57 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 09:59:57 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254736797.38.0.885294853984.issue5127@psf.upfronthosting.co.za>


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

> No, but changing the APIs from 16-bit integers to 32-bit integers
> does require a recompile of all code using it.

Is it acceptable between 3.1 and 3.2 for example? ISTM that other
changes already require recompilation of extension modules.

> Also, the Unicode type database itself uses Py_UNICODE, so
> case mapping would fail for non-BMP code points.

Where, please? in unicodedata.c, getuchar and _getrecord_ex use Py_UCS4.

----------

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

From report at bugs.python.org  Mon Oct  5 12:15:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 10:15:59 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1254736797.38.0.885294853984.issue5127@psf.upfronthosting.co.za>
Message-ID: <4AC9C75C.7090903@egenix.com>


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

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> No, but changing the APIs from 16-bit integers to 32-bit integers
>> does require a recompile of all code using it.
> 
> Is it acceptable between 3.1 and 3.2 for example? ISTM that other
> changes already require recompilation of extension modules.

With the proposed approach, we'll keep binary compatibility, so
this is not much of an issue.

Note: Changes to the binary interface can be done in minor releases,
but we should make sure that it's not possible to load an extension
compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.

>> Also, the Unicode type database itself uses Py_UNICODE, so
>> case mapping would fail for non-BMP code points.
> 
> Where, please? in unicodedata.c, getuchar and _getrecord_ex use Py_UCS4.

The change affects the Unicode type database which is implemented
in unicodectype.c, not the Unicode database, which already uses UCS4.

----------

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

From report at bugs.python.org  Mon Oct  5 13:09:34 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 11:09:34 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254740974.88.0.268460461251.issue5127@psf.upfronthosting.co.za>


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

> we should make sure that it's not possible to load an extension
> compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.

This is the case with this patch: today all these functions
(_PyUnicode_IsAlpha, _PyUnicode_ToLowercase) are actually #defines to
_PyUnicodeUCS2_* or _PyUnicodeUCS4_*.
The patch removes the #defines: 3.1 modules that call
_PyUnicodeUCS4_IsAlpha wouldn't load into a 3.2 interpreter.

> The change affects the Unicode type database which is implemented
> in unicodectype.c, not the Unicode database, which already uses UCS4.

Are you referring to the _PyUnicode_TypeRecord structure?
The first three fields only contains values up to 65535, so they could
use "unsigned short" even for UCS4 builds.
All the other uses are precisely changed by the patch...

----------

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

From report at bugs.python.org  Mon Oct  5 13:16:29 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Oct 2009 11:16:29 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254741389.65.0.268065306507.issue5127@psf.upfronthosting.co.za>


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

>> We might keep the old public API for compatibility, but it should be
>> clearly marked as broken for non-BMP scalar values.

> That has always been the case. UCS2 doesn't support surrogates.

> However, we have been slowly moving into the direction of making
> the UCS2 storage appear like UTF-16 to the Python programmer.

UCS2 died long ago, is there any reason why we keep using an UCS2 that
"appears" like UTF-16 instead of real UTF-16?

> This process is not yet complete and will likely never complete
> since it must still be possible to create things line lone
> surrogates for processing purposes, so care has to be taken
> when using non-BMP code points on narrow builds.

I don't exactly know all the details of the current implementation, but
-- from what I understand reading this (correct me if I'm wrong) -- it
seems that the implementation is half-UCS2 to allow things like the
processing of lone surrogates and half-UTF16 (or UTF-16-compatible) to
work with surrogate pairs and hence with chars outside the BMP.

What are the use cases for processing the lone surrogates? Wouldn't be
better to use UTF-16 and disallow them (since they are illegal) and
possibly provide some other way to deal with them (if it's really needed)?

----------

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

From report at bugs.python.org  Mon Oct  5 13:28:36 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Oct 2009 11:28:36 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Due to a change in distutils released with Python 2.6.3, packages that 
use setuptools (version 0.6c9, as of this writing), or the easy_install 
command, to build C extension modules fail with a cryptic message ending 
with:
... .egg/setuptools/command/build_ext.py", line 85, in get_ext_filename 
ext = self.ext_map[fullname] KeyError: <module_name>

Among the packages known to be affected include lxml, zope-interface, 
jinja2, and, hence, packages dependent on these packages (e.g. sphinx, 
twisted, etc.).

The issue is described in greater detail in the Distribute project 
tracker:
http://bitbucket.org/tarek/distribute/issue/41/keyerror-_speedups

The solution there was to modify Distribute, a fork of setuptools, to 
accommodate the change in distutils.

An issue has been opened on the setuptools tracker for this problem:
http://bugs.python.org/setuptools/issue85

A discussion on the distutils-sig mailing list starts here:
http://mail.python.org/pipermail/distutils-sig/2009-October/013534.html

The distutils change forces affected users to either:
(1) migrate from setuptools to Distribute, which can generally done by
    simply running:
          easy_install distribute
(2) avoid upgrading to 2.6.3 until a fix for setuptools is released
    (or patch setuptools themselves)
(3) patch or downgrade distutils to restore the previous behavior

The primary purpose of this issue is to serve as a placeholder for users 
searching the Python issue tracker for this failure symptom.

----------
assignee: tarek
components: Distutils
messages: 93591
nosy: barry, ned.deily, tarek
severity: normal
status: open
title: Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  5 13:33:50 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 11:33:50 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1254742430.61.0.843166988473.issue7042@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I think a timing out while loop explains much better what is happening. I 
mean we are trying to keep the cpu busy for 0.9 seconds (if I understand 
the definition of virtual time correctly) and not do 100000000 increments 
(which might be done faster than 0.9 seconds).

----------

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

From report at bugs.python.org  Mon Oct  5 13:39:01 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Oct 2009 11:39:01 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254742740.95.0.67108452829.issue7064@psf.upfronthosting.co.za>


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

> (3) patch or downgrade distutils to restore the previous behavior

This is not really an option since distutils code was modified to fix
some bugs, with no API change and no backward compat break. 

Users affected with this problems have to ask the Setuptools maintainer
to change the monkey-patches done on distutils and release a new
version, or have to use Distribute that fixes the problem and provide a
setuptools-compatible distribution.

As far as Distutils is concerned, its development and bug fixes will not
be frozen to make sure a 1 year old release of a tool that does
monkey-patches still work. It's up to this project to adapt its patches.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 13:41:17 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 11:41:17 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1254740974.88.0.268460461251.issue5127@psf.upfronthosting.co.za>
Message-ID: <4AC9DB5A.1030204@egenix.com>


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

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> we should make sure that it's not possible to load an extension
>> compiled with 3.1 in 3.2 to prevent segfaults and buffer overruns.
> 
> This is the case with this patch: today all these functions
> (_PyUnicode_IsAlpha, _PyUnicode_ToLowercase) are actually #defines to
> _PyUnicodeUCS2_* or _PyUnicodeUCS4_*.
> The patch removes the #defines: 3.1 modules that call
> _PyUnicodeUCS4_IsAlpha wouldn't load into a 3.2 interpreter.

True, but we can do better. For narrow builds, the API currently
exposes the UCS2 APIs. We'd need to expose the UCS4 APIs *in addition*
to those APIs and have the UCS2 APIs redirect to the UCS4 ones.

For wide builds, we don't need to change anything.

>> The change affects the Unicode type database which is implemented
>> in unicodectype.c, not the Unicode database, which already uses UCS4.
> 
> Are you referring to the _PyUnicode_TypeRecord structure?
> The first three fields only contains values up to 65535, so they could
> use "unsigned short" even for UCS4 builds.

I haven't checked, but it's certainly possible to have a code point
use a non-BMP lower/upper/title case mapping, so this should be
made possible as well, if we're going to make changes to the type
database.

----------

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

From report at bugs.python.org  Mon Oct  5 13:48:16 2009
From: report at bugs.python.org (steve steiner)
Date: Mon, 05 Oct 2009 11:48:16 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254743296.01.0.712298389971.issue7064@psf.upfronthosting.co.za>


Changes by steve steiner <ssteiner at users.sourceforge.net>:


----------
nosy: +ssteiner

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

From report at bugs.python.org  Mon Oct  5 13:51:28 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 11:51:28 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1254741389.65.0.268065306507.issue5127@psf.upfronthosting.co.za>
Message-ID: <4AC9DDBD.8050107@egenix.com>


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

This is off-topic for the tracker item, but I'll reply anyway:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
>>> We might keep the old public API for compatibility, but it should be
>>> clearly marked as broken for non-BMP scalar values.
> 
>> That has always been the case. UCS2 doesn't support surrogates.
> 
>> However, we have been slowly moving into the direction of making
>> the UCS2 storage appear like UTF-16 to the Python programmer.
> 
> UCS2 died long ago, is there any reason why we keep using an UCS2 that
> "appears" like UTF-16 instead of real UTF-16?

UCS2 is how we store Unicode in Python for narrow builds internally.
It's a storage format, not an encoding.

However, on narrow builds such as the Windows builds, you will sometimes
want to create Unicode strings that use non-BMP code points. Since
both UCS2 and UCS4 can represent the UTF-16 encoding, it's handy to
expose a bit of automatic conversion at the Python level to make
things easier for the programmer.

>> This process is not yet complete and will likely never complete
>> since it must still be possible to create things line lone
>> surrogates for processing purposes, so care has to be taken
>> when using non-BMP code points on narrow builds.
> 
> I don't exactly know all the details of the current implementation, but
> -- from what I understand reading this (correct me if I'm wrong) -- it
> seems that the implementation is half-UCS2 to allow things like the
> processing of lone surrogates and half-UTF16 (or UTF-16-compatible) to
> work with surrogate pairs and hence with chars outside the BMP.
> 
> What are the use cases for processing the lone surrogates? Wouldn't be
> better to use UTF-16 and disallow them (since they are illegal) and
> possibly provide some other way to deal with them (if it's really needed)?

No, because Python is meant to be used for working on all Unicode
code points. Lone surrogates are not allowed in transfer encodings
such as UTF-16 or UTF-8, but they are valid Unicode code points and
you need to be able to work with them, since you may want to construct
surrogate pairs by hand or get lone surrogates as a result of slicing a
Unicode string.

----------

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

From report at bugs.python.org  Mon Oct  5 14:28:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 12:28:44 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254745724.36.0.0195575889541.issue5127@psf.upfronthosting.co.za>


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

> We'd need to expose the UCS4 APIs *in addition*
> to those APIs and have the UCS2 APIs redirect to the UCS4 ones.

Why have two names for the same function? it's Python 3, after all.
Or is this "no recompile" feature so important (as long as changes are
clearly shown to the user)? It does not work on Windows, FWIW.

> I haven't checked, but it's certainly possible to have a code point
> use a non-BMP lower/upper/title case mapping, so this should be
> made possible as well, if we're going to make changes to the type
> database.

OK, here is a new patch.  Even if this does not happen with unicodedata
up to 5.1, the table has only 175 entries so memory usage is not
dramatically increased.
Py_UNICODE is no more used at all in unicodectype.c.

----------
Added file: http://bugs.python.org/file15047/unicodectype_ucs4-2.patch

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

From report at bugs.python.org  Mon Oct  5 14:33:22 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 12:33:22 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1254746002.9.0.50012647928.issue1571184@psf.upfronthosting.co.za>


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

Marc-Andre, could you comment on this patch?
The comments above were made by inspecting the generated code, comparing
with the previous version.
IMO the only drawback is the increased memory usage.

----------

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

From report at bugs.python.org  Mon Oct  5 14:37:39 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 12:37:39 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1254746259.96.0.236697437149.issue1571184@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file15048/unicodectype_ucs4-2.patch

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

From report at bugs.python.org  Mon Oct  5 14:38:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 12:38:07 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1254746287.84.0.277011334358.issue1571184@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15048/unicodectype_ucs4-2.patch

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

From report at bugs.python.org  Mon Oct  5 14:52:17 2009
From: report at bugs.python.org (Jan Hosang)
Date: Mon, 05 Oct 2009 12:52:17 +0000
Subject: [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1254747137.66.0.201255873291.issue7063@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

The mp_ass_subscript function looks fine in contrast to array_ass_slice(). 
So if array_ass_slice() is not accessible from the outside and is only 
called with NULL as replacement parameter from the inside, I won't be able 
to cause trouble with those two issues.

Still I think it's bad to keep buggy code around, even it is not used. 
Maybe array_ass_slice() should be changed to what it's used for: 
array_del_slice()?

----------

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

From report at bugs.python.org  Mon Oct  5 14:53:23 2009
From: report at bugs.python.org (egreen)
Date: Mon, 05 Oct 2009 12:53:23 +0000
Subject: [issue7065] bytes.maketrans segfaults
In-Reply-To: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
Message-ID: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>


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

The new maketrans static method in Python 3.1 segfaults when using byte
values > 127.

Reproduce: bytes.maketrans(bytes(range(256)), b'X' * 256)

Cause: _Py_bytes_maketrans in Objects/bytes_methods.c uses signed int as
array index.

Fix attached. Also adds test.

----------
components: Interpreter Core
files: maketrans_segfault.patch
keywords: patch
messages: 93599
nosy: egreen
severity: normal
status: open
title: bytes.maketrans segfaults
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15049/maketrans_segfault.patch

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

From report at bugs.python.org  Mon Oct  5 14:55:03 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 12:55:03 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
In-Reply-To: <1254746002.9.0.50012647928.issue1571184@psf.upfronthosting.co.za>
Message-ID: <4AC9ECA4.5050000@egenix.com>


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

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Marc-Andre, could you comment on this patch?
> The comments above were made by inspecting the generated code, comparing
> with the previous version.
> IMO the only drawback is the increased memory usage.

I haven't tried applying the patch, but from reading it, it looks
good.

----------

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

From report at bugs.python.org  Mon Oct  5 15:18:12 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 05 Oct 2009 13:18:12 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1254748692.71.0.707467874628.issue7060@psf.upfronthosting.co.za>


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

Adding gps - I haven't had a chance to grok the changes, and me getting to 
a fix is going to take a few.

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

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

From report at bugs.python.org  Mon Oct  5 15:23:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Oct 2009 13:23:48 +0000
Subject: [issue7065] bytes.maketrans segfaults
In-Reply-To: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
Message-ID: <1254749028.53.0.968167913542.issue7065@psf.upfronthosting.co.za>


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

Good catch!
Shouldn't the "i" variable be a "Py_ssize_t"?

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

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

From report at bugs.python.org  Mon Oct  5 15:36:28 2009
From: report at bugs.python.org (egreen)
Date: Mon, 05 Oct 2009 13:36:28 +0000
Subject: [issue7065] bytes.maketrans segfaults
In-Reply-To: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
Message-ID: <1254749788.84.0.280221733404.issue7065@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

Yes, it should indeed be a Py_ssize_t.

New patch.

----------
Added file: http://bugs.python.org/file15050/bytes_maketrans_2.patch

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

From report at bugs.python.org  Mon Oct  5 16:16:26 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 14:16:26 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1254745724.36.0.0195575889541.issue5127@psf.upfronthosting.co.za>
Message-ID: <4AC9FFB7.1050204@egenix.com>


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

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> We'd need to expose the UCS4 APIs *in addition*
>> to those APIs and have the UCS2 APIs redirect to the UCS4 ones.
> 
> Why have two names for the same function? it's Python 3, after all.

It's not the same function... the UCS2 version would take a
Py_UNICODE parameter, the UCS4 version a Py_UCS4 parameter.

I don't understand the comment about Python 3.x. FWIW, we're no
longer in the backwards incompatible changes are allowed mode
for 3.x.

> Or is this "no recompile" feature so important (as long as changes are
> clearly shown to the user)? It does not work on Windows, FWIW.

There are generally two options for API changes within a
major release branch:

 1. the changes are API backwards compatible and only the Python API
    version is changed

 2. the changes are not API backwards compatible; in such a case,
    Python has to reject imports of old module (as it always
    does on Windows), so the Python API version has to be changed
    *and* the import mechanism must reject the import

The second option was used when transitioning from 2.4 to 2.5 due
to the Py_ssize_t changes.

We could do the same for 2.7/3.2, but if it's just needed for this
one change, then I'd rather stick to implementing the first option.

>> I haven't checked, but it's certainly possible to have a code point
>> use a non-BMP lower/upper/title case mapping, so this should be
>> made possible as well, if we're going to make changes to the type
>> database.
> 
> OK, here is a new patch.  Even if this does not happen with unicodedata
> up to 5.1, the table has only 175 entries so memory usage is not
> dramatically increased.
> Py_UNICODE is no more used at all in unicodectype.c.

Sorry, but this doesn't work: the functions have to return Py_UNICODE
and raise an exception if the return value doesn't fit.

Otherwise, you'd get completely wrong values in code downcasting
the return value to Py_UNICODE on narrow builds.

Another good reason to use two sets of APIs. The new set could
indeed return Py_UCS4 values.

----------

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

From report at bugs.python.org  Mon Oct  5 17:16:22 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 05 Oct 2009 15:16:22 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1254755782.92.0.341645584523.issue7060@psf.upfronthosting.co.za>


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

It's passing for me on trunk/py3k at least on OS/X - I'm going to need to 
dredge up a linuxvm

----------

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

From report at bugs.python.org  Mon Oct  5 17:37:22 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2009 15:37:22 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254757042.74.0.471497061157.issue7064@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Before we start pointing fingers or throwing mud, was this bug fix which 
apparently breaking setuptools introduced knowing that this would break 
setuptools users?

I'm surprised that nobody at all tried to use the release candidate with 
any of the listed packages.

Given the number of packages that use setuptools and have been widely 
distributed, I expect that even if a fixed version of setuptools was 
released tomorrow, the damage would already be done, and most people 
would just have to avoid 2.6.3.

How hard would it be to release a 2.6.4 which differs from 2.6.3 only by 
not breaking existing setuptools distros?

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Mon Oct  5 18:05:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Oct 2009 16:05:17 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254758717.22.0.445107410515.issue7058@psf.upfronthosting.co.za>


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

Apart from the comments I made on IRC, I think it would be nice to have
this patch in 2.6 and 3.1 as well. While not technically a bug fix, it
is innocuous for users and certainly helps finding problems.

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

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

From report at bugs.python.org  Mon Oct  5 18:07:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2009 16:07:45 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254758865.75.0.302704333519.issue7058@psf.upfronthosting.co.za>


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

Updated patch based on Antoine's feedback on IRC.  Removes a mislaid
'not quiet' and restores argv using argv[:] = saved_argv.

I agree about putting it into 2.6/3.1.  We could also claim that it is
fixing a bug in the running of the tests :)  I suspect it might make the
buildbots more stable, for example.

----------
Added file: http://bugs.python.org/file15051/regrtest_guards.patch

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

From report at bugs.python.org  Mon Oct  5 18:22:07 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Oct 2009 16:22:07 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254759727.0.0.705868476069.issue7064@psf.upfronthosting.co.za>


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

> Before we start pointing fingers or throwing mud, was this bug 
> fix which apparently breaking setuptools introduced knowing that 
> this would break setuptools users?
>
> I'm surprised that nobody at all tried to use the release candidate 
> with any of the listed packages.

The final release of 2.6.3 was done very shortly after the rc, so 
the community didn't have enough time to test their package with 
the rc.

What should have been done to avoid this (what what was suggested) is to
have a special buildbot for this that would run distutils commands over
a list of packages from the community.

I have a buidbot myself that does this, but it was discontinued lately 
because of a lack of CPU/Bandwidth.

> How hard would it be to release a 2.6.4 which differs from 2.6.3 
> only by not breaking existing setuptools distros?

I could work on this by making a special internal case in Distutils to
avoid calling the patched API that leads to the setuptools bug. This is
not hard and can be done quickly if required.

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

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

From report at bugs.python.org  Mon Oct  5 19:15:21 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2009 17:15:21 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1254762921.87.0.262497791967.issue7057@psf.upfronthosting.co.za>


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

A somewhat separate issue is the lack of even a mention of the existence
of the Canvas widget, which would merit a separate subsection if
documented. I think it should at least be mentioned with a reference to
the online reference materials listed before.

Indeed, the tkinter reference should somewhere have a complete list of
widgets, just like the ttk section does

24.2.2. Ttk Widgets?

Ttk comes with 17 widgets, eleven of which already existed in tkinter:
Button, Checkbutton, Entry, Frame, Label, LabelFrame, Menubutton,
PanedWindow, Radiobutton, Scale and Scrollbar. The other six are new:
Combobox, Notebook, Progressbar, Separator, Sizegrip and Treeview. And
all them are subclasses of Widget.

----------

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

From report at bugs.python.org  Mon Oct  5 19:25:50 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 05 Oct 2009 17:25:50 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <4AC9B649.7040308@egenix.com>
Message-ID: <aac2c7cb0910051025o71f16947v79ca24546a3935f4@mail.gmail.com>


Adam Olsen <rhamph at gmail.com> added the comment:

On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg <report at bugs.python.org> wrote:
> We use UCS2 on narrow Python builds, not UTF-16.
>
>> We might keep the old public API for compatibility, but it should be
>> clearly marked as broken for non-BMP scalar values.
>
> That has always been the case. UCS2 doesn't support surrogates.
>
> However, we have been slowly moving into the direction of making
> the UCS2 storage appear like UTF-16 to the Python programmer.
>
> This process is not yet complete and will likely never complete
> since it must still be possible to create things line lone
> surrogates for processing purposes, so care has to be taken
> when using non-BMP code points on narrow builds.

Balderdash.  We expose UTF-16 code units, not UCS-2.  Guido has made
this quite clear.

UTF-16 was designed as an easy transition from UCS-2.  Indeed, if your
code only does searches or joins existing strings then it will Just
Work; declare it UTF-16 and you are done.  We have a lot more work to
do than that (as in this bug report), and we can't reasonably prevent
the user from splitting surrogate pairs via poor code, but a 95%
solution doesn't mean we suddenly revert all the way back to UCS-2.

If the intent really was to use UCS-2 then a correctly functioning
UTF-16 codec would join a surrogate pair into a single scalar value,
then raise an error because it's outside the range representable in
UCS-2.  That's not very helpful though; obviously, it's much better to
use UTF-16 internally.

"The alternative (no matter what the configure flag is called) is
UTF-16, not UCS-2 though: there is support for surrogate pairs in
various places, including the \U escape and the UTF-8 codec."
http://mail.python.org/pipermail/python-dev/2008-July/080892.html

"If you find places where the Python core or standard library is doing
Unicode processing that would break when surrogates are present you
should file a bug. However this does not mean that every bit of code
that slices a string at an arbitrary point (and hence risks slicing in
the middle of a surrogate) is incorrect -- it all depends on what is
done next with the slice."
http://mail.python.org/pipermail/python-dev/2008-July/080900.html

----------

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

From report at bugs.python.org  Mon Oct  5 19:36:27 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Oct 2009 17:36:27 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254764187.14.0.476031755595.issue7064@psf.upfronthosting.co.za>


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

Done in r75256

----------

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

From report at bugs.python.org  Mon Oct  5 19:55:19 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2009 17:55:19 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254765319.75.0.194018782825.issue7064@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks for the quick action Tarek!!!

----------

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

From report at bugs.python.org  Mon Oct  5 20:01:11 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 05 Oct 2009 18:01:11 +0000
Subject: [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254765671.55.0.673189429327.issue7022@psf.upfronthosting.co.za>


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

Thanks a lot B-)

----------

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

From report at bugs.python.org  Mon Oct  5 20:10:20 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Oct 2009 18:10:20 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <aac2c7cb0910051025o71f16947v79ca24546a3935f4@mail.gmail.com>
Message-ID: <4ACA3686.4060307@egenix.com>


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

Adam Olsen wrote:
> 
> Adam Olsen <rhamph at gmail.com> added the comment:
> 
> On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg <report at bugs.python.org> wrote:
>> We use UCS2 on narrow Python builds, not UTF-16.
>>
>>> We might keep the old public API for compatibility, but it should be
>>> clearly marked as broken for non-BMP scalar values.
>>
>> That has always been the case. UCS2 doesn't support surrogates.
>>
>> However, we have been slowly moving into the direction of making
>> the UCS2 storage appear like UTF-16 to the Python programmer.
>>
>> This process is not yet complete and will likely never complete
>> since it must still be possible to create things line lone
>> surrogates for processing purposes, so care has to be taken
>> when using non-BMP code points on narrow builds.
> 
> Balderdash.  We expose UTF-16 code units, not UCS-2.  Guido has made
> this quite clear.
> 
> UTF-16 was designed as an easy transition from UCS-2.  Indeed, if your
> code only does searches or joins existing strings then it will Just
> Work; declare it UTF-16 and you are done.  We have a lot more work to
> do than that (as in this bug report), and we can't reasonably prevent
> the user from splitting surrogate pairs via poor code, but a 95%
> solution doesn't mean we suddenly revert all the way back to UCS-2.
> 
> If the intent really was to use UCS-2 then a correctly functioning
> UTF-16 codec would join a surrogate pair into a single scalar value,
> then raise an error because it's outside the range representable in
> UCS-2.  That's not very helpful though; obviously, it's much better to
> use UTF-16 internally.
> 
> "The alternative (no matter what the configure flag is called) is
> UTF-16, not UCS-2 though: there is support for surrogate pairs in
> various places, including the \U escape and the UTF-8 codec."
> http://mail.python.org/pipermail/python-dev/2008-July/080892.html
> 
> "If you find places where the Python core or standard library is doing
> Unicode processing that would break when surrogates are present you
> should file a bug. However this does not mean that every bit of code
> that slices a string at an arbitrary point (and hence risks slicing in
> the middle of a surrogate) is incorrect -- it all depends on what is
> done next with the slice."
> http://mail.python.org/pipermail/python-dev/2008-July/080900.html

All this is just nitpicking, really. UCS2 is a character set,
UTF-16 an encoding.

It so happens that when the Unicode consortium realized
that 16 bit would not be enough to represent all scripts of the
world, they added the concept of surrogates and reserved a few
ranges of code points in UCS2 to represent these extra code
points which are not part of UCS2, but the extensions UCS4.

The conversion of these surrogate pairs to UCS4 code point
values is what you find defined in UTF-16.

If we were to implement Unicode using UTF-16 as storage format,
we would not be able to store single lone surrogates, since these
are not allowed in UTF-16. Ditto for unassigned ordinals, invalid
code points, etc.

PEP 100 really says it all:

	http://www.python.org/dev/peps/pep-0100/

"""
    This [internal] format will hold UTF-16 encodings of the corresponding
    Unicode ordinals.  The Python Unicode implementation will address
    these values as if they were UCS-2 values. UCS-2 and UTF-16 are
    the same for all currently defined Unicode character points.
...
    Future implementations can extend the 16 bit restriction to the
    full set of all UTF-16 addressable characters (around 1M
    characters).
"""

Note that I wrote the PEP and worked on the implementation at a time
when Unicode 2.x was still in use wide-spread use (mostly on Windows)
and 3.0 was just being release:

	http://www.unicode.org/history/publicationdates.html

But all that is off-topic for this ticket, so please let's just
stop such discussions.

----------

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

From report at bugs.python.org  Mon Oct  5 20:27:45 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Oct 2009 18:27:45 +0000
Subject: [issue7065] bytes.maketrans segfaults
In-Reply-To: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
Message-ID: <1254767265.22.0.847384942305.issue7065@psf.upfronthosting.co.za>


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


----------
priority:  -> release blocker
type:  -> crash

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

From report at bugs.python.org  Mon Oct  5 20:36:00 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Mon, 05 Oct 2009 18:36:00 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254767760.77.0.992969237938.issue7064@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

I appreciate the change being made.  The specific code in setuptools is
relying on an erroneous reading of get_ext_filename()'s docstring (which
as of 2.3 at least, implied to me at least that it is always called with
an extension's full dotted name), and so I will fix it in setuptools as
well.

I would like to point out, however, that subclassing is not
"monkeypatching".  The distutils explicitly documents the ability to
extend and subclass commands, and this particular subclassing was based
on code provided by another distutils user, who'd extended build_ext to
support building dynamic libraries.

It is likely that that user, and anyone else who extended the build_ext
command in a similar way (e.g. numpy's and Twisted's distutils
extensions), could be affected by the change.

So, this was neither a matter of monkeypatching, nor special treatment
for setuptools.  Setuptools is far from the first or last distutils
extension ever written, and build_ext tends to get extended more than
most other commands.  It's important to remember subclassing use cases
when modifying distutils commands; subclasses inherently rely on a
stricter interface than a class's public API.

----------
nosy: +pje

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

From report at bugs.python.org  Mon Oct  5 20:48:55 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 05 Oct 2009 18:48:55 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <4ACA3686.4060307@egenix.com>
Message-ID: <aac2c7cb0910051148y75a87640ye5c0bd674fb5416d@mail.gmail.com>


Adam Olsen <rhamph at gmail.com> added the comment:

On Mon, Oct 5, 2009 at 12:10, Marc-Andre Lemburg <report at bugs.python.org> wrote:
> All this is just nitpicking, really. UCS2 is a character set,
> UTF-16 an encoding.

UCS is a character set, for most purposes synonymous with the Unicode
character set.  UCS-2 and UTF-16 are both encodings of that character
set.  However, UCS-2 can only represent the BMP, while UTF-16 can
represent the full range.

> If we were to implement Unicode using UTF-16 as storage format,
> we would not be able to store single lone surrogates, since these
> are not allowed in UTF-16. Ditto for unassigned ordinals, invalid
> code points, etc.

No.  Internal usage may become temporarily ill-formed, but this is a
compromise, and acceptable so long as we never export them to other
systems.

Not that I wouldn't *prefer* a system that wouldn't store lone
surrogates, but.. pragmatics prevail.

> Note that I wrote the PEP and worked on the implementation at a time
> when Unicode 2.x was still in use wide-spread use (mostly on Windows)
> and 3.0 was just being release:
>
> ? ? ? ?http://www.unicode.org/history/publicationdates.html

I think you hit the nail on the head there.  10 years ago, unicode
meant something different than it does today.  That's reflected in PEP
100 and in the code.  Now it's time to move on, switch to the modern
terminology, modern usage, and modern specs.

> But all that is off-topic for this ticket, so please let's just
> stop such discussions.

It needs to be discussed somewhere.  It's a distraction from fixing
the bug, but at least it's more private here.  Would you prefer email?

----------

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

From report at bugs.python.org  Mon Oct  5 21:19:41 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 05 Oct 2009 19:19:41 +0000
Subject: [issue7052] "from logging import *" causes an error under Ubuntu
	Karmic
In-Reply-To: <1254640849.21.0.615783238878.issue7052@psf.upfronthosting.co.za>
Message-ID: <1254770381.74.0.998831213605.issue7052@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Mon Oct  5 21:40:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Oct 2009 19:40:27 +0000
Subject: [issue7066] archive_util.make_archive doesn't restore the cwd if an
	error is raised
In-Reply-To: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
Message-ID: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>


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

archive_util.make_archive() changes the value of the cwd, but if an
error is raised in "filename = func(base_name, base_dir, **kwargs)", the
cwd is not restored. This may happen if zlib is not available and causes
other ~60 tests to fail while running regrtest.py.

This trivial fix solve the problem here:

-    filename = func(base_name, base_dir, **kwargs)
-    if root_dir is not None:
-        log.debug("changing back to '%s'", save_cwd)
-        os.chdir(save_cwd)
+    try:
+        filename = func(base_name, base_dir, **kwargs)
+    finally:
+        if root_dir is not None:
+            log.debug("changing back to '%s'", save_cwd)
+            os.chdir(save_cwd)

The new test_make_archive_owner_group() test added in r75192 also needs
a @unittest.skipUnless(zlib, "Requires zlib"), otherwise dist_distutils
fails.
Since half of this test doesn't require zlib (i.e. when 'tar' is used)
it might be a good idea to split the test in two, in order to test the
'tar' archives even if 'zlib' is not available.

(Thanks to R. David Murray - he spot the right place where the cwd is
changed and not restored.)

----------
assignee: tarek
components: Distutils
messages: 93618
nosy: ezio.melotti, r.david.murray, tarek
priority: normal
severity: normal
status: open
title: archive_util.make_archive doesn't restore the cwd if an error is raised
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Oct  5 22:35:54 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2009 20:35:54 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1254774954.41.0.589480343123.issue7057@psf.upfronthosting.co.za>


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

This "The authors strongly suggest getting a copy of the Tk man pages. "
should be followed by a mention that they are available at the active
state site, in particular, at http://www.tcl.tk/man/tcl8.5/

----------

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

From report at bugs.python.org  Mon Oct  5 22:48:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Oct 2009 20:48:30 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254775710.7.0.889109384648.issue7064@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


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

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

From report at bugs.python.org  Mon Oct  5 22:48:57 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Oct 2009 20:48:57 +0000
Subject: [issue7066] archive_util.make_archive doesn't restore the cwd if an
	error is raised
In-Reply-To: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
Message-ID: <1254775737.01.0.377460707039.issue7066@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


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

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

From report at bugs.python.org  Mon Oct  5 22:52:10 2009
From: report at bugs.python.org (Steven R. Loomis)
Date: Mon, 05 Oct 2009 20:52:10 +0000
Subject: [issue7067] Suggest better documentation of 2 versus 3 on 3.1.1 site.
In-Reply-To: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
Message-ID: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>


New submission from Steven R. Loomis <srl at monkey.sbay.org>:

It would be nice if http://www.python.org/download/releases/3.1.1/ had 
the '3 vs 2' explanation made more prominent, just as it was in the 3.0. 
Maybe I've been living under a rock, but I didn't realize that 3 was 
such a change.  Maybe the words 'backwards-incompatible' could be a link 
to  http://docs.python.org/dev/3.0/whatsnew/3.0.html  which explained 
things quite nicely.  You could also add something on the home page, 
with a link to that same page under the title "3 versus 2?"  

Please consider the scenario where someone "needs python installed" to 
run an existing program, and they go to http://www.python.org - wanting 
to download the latest version would be the logical thing to do.  You 
could use this opportunity to suggest running the 2to3 converter and so 
upgrading their existing program.  Again, the 3.1.1 release page doesn't 
have the link to 2to3, but 3.0 does.

Thank you for your consideration.

----------
assignee: georg.brandl
components: Documentation
messages: 93620
nosy: georg.brandl, srl
severity: normal
status: open
title: Suggest better documentation of 2 versus 3 on 3.1.1 site.
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Mon Oct  5 23:03:49 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 05 Oct 2009 21:03:49 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254776629.12.0.901091676534.issue7064@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Mon Oct  5 23:24:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Oct 2009 21:24:45 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254777885.33.0.585885771771.issue5949@psf.upfronthosting.co.za>


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

Can this go into 2.6.4?

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

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

From report at bugs.python.org  Mon Oct  5 23:25:16 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Oct 2009 21:25:16 +0000
Subject: [issue7066] archive_util.make_archive doesn't restore the cwd if an
	error is raised
In-Reply-To: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
Message-ID: <1254777916.92.0.498124730658.issue7066@psf.upfronthosting.co.za>


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

I see two distinct points (besides test_make_archive_owner_group):

1- having a try..finally when changing the current working dir (I'll do
this thanks for the patch)

2- dealing with calls made on archive_util.make_archive() when zlib is
not available. What error do you get ? CompressionError I guess ?

----------

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

From report at bugs.python.org  Mon Oct  5 23:25:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Oct 2009 21:25:31 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254777931.83.0.325819286056.issue3890@psf.upfronthosting.co.za>


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

2.6.4?

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

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

From report at bugs.python.org  Mon Oct  5 23:27:16 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Oct 2009 21:27:16 +0000
Subject: [issue7066] archive_util.make_archive doesn't restore the cwd if an
	error is raised
In-Reply-To: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
Message-ID: <1254778036.97.0.792293816593.issue7066@psf.upfronthosting.co.za>


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

======================================================================
ERROR: test_make_archive_owner_group
(distutils.tests.test_archive_util.ArchiveUtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/dev/trunk/Lib/distutils/tests/test_archive_util.py",
line 224, in test_make_archive_owner_group
    group=group)
  File "/home/wolf/dev/trunk/Lib/distutils/archive_util.py", line 237,
in make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/home/wolf/dev/trunk/Lib/distutils/archive_util.py", line 163,
in make_zipfile
    compression=zipfile.ZIP_DEFLATED)
  File "/home/wolf/dev/trunk/Lib/zipfile.py", line 675, in __init__
    "Compression requires the (missing) zlib module"
RuntimeError: Compression requires the (missing) zlib module

----------

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

From report at bugs.python.org  Mon Oct  5 23:30:11 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 05 Oct 2009 21:30:11 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1254778211.52.0.0912096638706.issue3890@psf.upfronthosting.co.za>


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

>From http://bugs.python.org/msg93606 .. it seems that 2.6.4 may happen 
very soon.

----------

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

From report at bugs.python.org  Mon Oct  5 23:41:00 2009
From: report at bugs.python.org (Eduardo Aguiar)
Date: Mon, 05 Oct 2009 21:41:00 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254778860.64.0.475786165645.issue5395@psf.upfronthosting.co.za>


Eduardo Aguiar <aguiar at users.sourceforge.net> added the comment:

Maybe you could create a file without read permission (000) and try
to read from it.

----------

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

From report at bugs.python.org  Tue Oct  6 02:43:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Oct 2009 00:43:22 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254789802.37.0.350832235412.issue7064@psf.upfronthosting.co.za>


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

UPDATE for users: With the change to distutils now added in r75256 and a 
2.6.4 release in the works, option (3) in the original message should now 
read:

(3) patch distutils to restore the previous behavior or
    install Python 2.6.4 which is expected to be released within a
    few weeks

----------

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

From report at bugs.python.org  Tue Oct  6 02:53:26 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 06 Oct 2009 00:53:26 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254790406.12.0.665972462589.issue7064@psf.upfronthosting.co.za>


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

> a 2.6.4 release in the works

Is this going to have a rc1 as usual? Have we decided on the dates both 
for rc1 and final?

----------

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

From report at bugs.python.org  Tue Oct  6 03:27:06 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 06 Oct 2009 01:27:06 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254792426.79.0.789848456665.issue7064@psf.upfronthosting.co.za>


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

yes.  rc1 on 6 oct 2009 and final on 18 oct 2009 (tentative)

----------

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

From report at bugs.python.org  Tue Oct  6 05:12:05 2009
From: report at bugs.python.org (Shun-ichi Goto)
Date: Tue, 06 Oct 2009 03:12:05 +0000
Subject: [issue7068] 2.6.3 does not use specified compiler
In-Reply-To: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
Message-ID: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>


New submission from Shun-ichi Goto <shunichi.goto at gmail.com>:

I installed python 2.6.3 on windows from .msi installer and get problem
to build ext modules with MinGW compiler.

It seems that Python 2.6.3 does not use compiler specified by user
via --compiler=xxx or setup.cfg on building ext module. Thus, MSVC
compiler is always used or show unreasonable error message
"error: Unable to find vcvarsall.bat" although specifying
--compiler=mingw32.

I found the change of r72594 cause this issue.

  [projects] Diff of
/python/branches/release26-maint/Lib/distutils/command/build_ext.py
 
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/command/build_ext.py?view=diff&r1=72593&r2=72594

And following patch get the behaviour like before, but I don't 
see why this change is introduced (merged from trunk).

{{{
diff -r 5874f642b473 distutils/command/build_ext.py
--- a/distutils/command/build_ext.py	Tue Oct 06 10:39:34 2009 +0900
+++ b/distutils/command/build_ext.py	Tue Oct 06 10:43:14 2009 +0900
@@ -303,7 +303,7 @@
 
         # Setup the CCompiler object that we'll use to do all the
         # compiling and linking
-        self.compiler = new_compiler(compiler=None,
+        self.compiler = new_compiler(compiler=self.compiler,
                                      verbose=self.verbose,
                                      dry_run=self.dry_run,
                                      force=self.force)

}}}

Is there any changes the way to specifying compiler?

----------
assignee: tarek
components: Distutils
messages: 93630
nosy: gotoh, tarek
severity: normal
status: open
title: 2.6.3 does not use specified compiler
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  6 06:32:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 06 Oct 2009 04:32:42 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>


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

Currently, inspect.isabstract() may return an integer like 1048576 
instead of True, or 0 instead of False.

Although technically correct, no other isXXX function behaves that way; 
also, isgeneratorfunction() uses a similar code construct but casts the 
result into a boolean.

The attached patch makes inspect.isabstract() return a boolean value 
always.

----------
components: Library (Lib)
files: inspect.diff
keywords: patch
messages: 93631
nosy: gagenellina
severity: normal
status: open
title: inspect.isabstract to return boolean values only
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15052/inspect.diff

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

From report at bugs.python.org  Tue Oct  6 08:24:36 2009
From: report at bugs.python.org (Jan Hosang)
Date: Tue, 06 Oct 2009 06:24:36 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254810276.11.0.323682183553.issue5395@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

> Maybe you could create a file without read permission (000) and try
> to read from it.

I just checked. If I don't have read permissions, I am not able to open 
the file. When I open a file and change permissions afterwards, I can read 
the complete file alright. (Checked with a 4mb file, I hope that's beyond 
buffering.) So I guess permissions are only checked when you open the 
file.

----------

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

From report at bugs.python.org  Tue Oct  6 08:49:56 2009
From: report at bugs.python.org (Jan Hosang)
Date: Tue, 06 Oct 2009 06:49:56 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1254811796.99.0.199512916329.issue7069@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

The patch works, as this is what is implicitly happening anyway if you use 
the function. There seem to be no tests for this function, so there is 
nothing to break. I guess this is the right time to get some tests. 

Gabriel, would you like to write tests for this function?

----------
nosy: +chuck

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

From report at bugs.python.org  Tue Oct  6 09:36:45 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Oct 2009 07:36:45 +0000
Subject: [issue7068] 2.6.3 does not use specified compiler
In-Reply-To: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
Message-ID: <1254814605.78.0.0490773823376.issue7068@psf.upfronthosting.co.za>


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

Thanks for reporting this.

It appears that Benjamin tried to undo the .compiler attribute renaming
Tarek had applied and r72586, but forgot to change back line 303 to the
original version:

{{{
        # Setup the CCompiler object that we'll use to do all the
        # compiling and linking
        self.compiler = new_compiler(compiler=self.compiler,
                                     verbose=self.verbose,
                                     dry_run=self.dry_run,
                                     force=self.force)
}}}

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

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

From report at bugs.python.org  Tue Oct  6 10:38:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Oct 2009 08:38:45 +0000
Subject: [issue7070] round(x) gives wrong result for large odd integers
In-Reply-To: <1254818325.66.0.811291436482.issue7070@psf.upfronthosting.co.za>
Message-ID: <1254818325.66.0.811291436482.issue7070@psf.upfronthosting.co.za>


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

The single-argument form of the builtin round function can give
incorrect results for large integers.

>>> x = 5e15+1
>>> x == int(x)
True
>>> x == round(x)  # expect True here
False
>>> x
5000000000000001.0
>>> round(x)
5000000000000002.0
>>> int(x)
5000000000000001

This is already fixed in trunk (and in 3.x);  the fix needs to be
backported to release26-maint.

----------
assignee: mark.dickinson
keywords: easy
messages: 93635
nosy: mark.dickinson
priority: high
severity: normal
stage: needs patch
status: open
title: round(x) gives wrong result for large odd integers
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  6 10:52:31 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Oct 2009 08:52:31 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254819151.18.0.186597127594.issue5127@psf.upfronthosting.co.za>


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

So the discussion is now on 2 points:

1. Is the change backwards compatible? (at the code level, after
recompilation).  My answer is yes, because all known case
transformations stay in the same plane: if you pass a char in the BMP,
they return a char in the BMP; if you pass a code >0x1000, you get
another code >0x1000. In other words: in narrow builds, when you pass
Py_UNICODE, the answer will be correct even when downcasted to
Py_UNICODE.  If you want, I can add checks to makeunicodedata.py to
verify that future Unicode standards don't break this statement.

"Naive" code that simply walks the Py_UNICODE* buffer will have
identical behavior.  (The current unicode methods are in this case. 
They should be fixed, later)

2. Is this change acceptable for 3.2?  I'd say yes, because existing
extension modules that use these functions will need to be recompiled;
the functions names change, the modules won't load otherwise.  There is
no need to change the API number for this.

----------

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

From report at bugs.python.org  Tue Oct  6 10:53:16 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 06 Oct 2009 08:53:16 +0000
Subject: [issue7068] 2.6.3 does not use specified compiler
In-Reply-To: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
Message-ID: <1254819196.79.0.431182363063.issue7068@psf.upfronthosting.co.za>


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

Thanks for noticing, I'll rename it in the maintenance branch, but I
need to wait for Barry to give me the green light since the 2.6 branch
is frozen right now.

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

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

From report at bugs.python.org  Tue Oct  6 12:51:22 2009
From: report at bugs.python.org (Bheemesh)
Date: Tue, 06 Oct 2009 10:51:22 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1254826282.69.0.95120224977.issue6516@psf.upfronthosting.co.za>


Bheemesh <bheemesh at gmail.com> added the comment:

Hello Tarek,

done in r75192 and r75194. Thanks Till !

Can you please tell me how to get this correction into use?

----------
nosy: +bheemesh

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

From report at bugs.python.org  Tue Oct  6 12:55:47 2009
From: report at bugs.python.org (Bert Vermeulen)
Date: Tue, 06 Oct 2009 10:55:47 +0000
Subject: [issue1282647] socket.getaddrinfo() bug for IPv6 enabled platforms
Message-ID: <1254826547.75.0.220726880278.issue1282647@psf.upfronthosting.co.za>


Bert Vermeulen <bert at biot.com> added the comment:

This is not a python bug, but a bug in the underlying libc. A simple
getaddrinfo() call in C exhibits the exact same behavior. It has been
fixed at some point; I see this bug on Centos 3.3 but not on Centos 4.4,
for example.

I've attached a small C demo that will fail on Centos 3.3, but work on
more recent platforms.

----------
nosy: +biot
Added file: http://bugs.python.org/file15053/gai.c

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

From report at bugs.python.org  Tue Oct  6 13:11:43 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 06 Oct 2009 11:11:43 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>


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

distutils package installation isn't compatible with IronPython.

To reproduce first install IronPython 2.6 (RC1 is currently latest
version) from the msi installer. This installs by default on Windows
into "C:\Program Files\IronPython 2.6" and includes a "site-packages"
folder in the "Lib" subfolder.

With the simplest Python package created with "python setup.py sdist"
(CPython) from the first example in the distutils documentation I get
the following on install:

C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
creating build
creating build\lib
copying foo.py -> build\lib
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
error: C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py: None

C:\compile\test\foo-1.0>dir "C:\Program Files\IronPython
2.6\Lib\site-packages"

 Volume in drive C has no label.
 Volume Serial Number is FC33-85DD

 Directory of C:\Program Files\IronPython 2.6\Lib\site-packages

06/10/2009  11:37    <DIR>          .
06/10/2009  11:37    <DIR>          ..
15/09/2009  08:53               121 README.txt
               1 File(s)            121 bytes
               2 Dir(s)  71,854,129,152 bytes free


See also the following bug report against IronPython on the codeplex
issue tracker. Here the distutils install fails in bytecode compilation. 

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24810

Bytecode compilation should not be attempted on IronPython as it does
not use Python bytecode. ( sys.dont_write_bytecode is True )

The fixes should be backported to Python 2.6 *if possible* as IronPython
2.6 uses the standard library from SVN and will pick up changes even
between releases.

----------
assignee: tarek
messages: 93640
nosy: michael.foord, tarek
severity: normal
stage: needs patch
status: open
title: distutils and IronPython compatibility
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Oct  6 13:11:50 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 06 Oct 2009 11:11:50 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1254827510.58.0.988297345076.issue7071@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


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

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

From report at bugs.python.org  Tue Oct  6 13:41:01 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 06 Oct 2009 11:41:01 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1254829261.92.0.686373408095.issue7071@psf.upfronthosting.co.za>


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

Hmmm... ok, so I was running on Vista where a normal user can't create
files in the "Program Files" directory anyway. If I run with elevated
permissions then I get the same error as reported on the IronPython
issue on codeplex (which is probably what you will see if you try this
on Windows XP):

C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
byte-compiling C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py
to foo.p
yc
Traceback (most recent call last):
  File "setup.py", line 2, in setup.py
  File "C:\Program Files\IronPython 2.6\Lib\distutils\core.py", line
152, in set
up
  File "C:\Program Files\IronPython 2.6\Lib\distutils\dist.py", line
975, in run
_commands
  File "C:\Program Files\IronPython 2.6\Lib\distutils\dist.py", line
995, in run
_command
  File "C:\Program Files\IronPython
2.6\Lib\distutils\command\install.py", line
589, in run
  File "C:\Program Files\IronPython 2.6\Lib\distutils\cmd.py", line 333,
in run_
command
  File "C:\Program Files\IronPython 2.6\Lib\distutils\dist.py", line
995, in run
_command
  File "C:\Program Files\IronPython
2.6\Lib\distutils\command\install_lib.py", l
ine 100, in run
  File "C:\Program Files\IronPython
2.6\Lib\distutils\command\install_lib.py", l
ine 134, in byte_compile
  File "C:\Program Files\IronPython 2.6\Lib\distutils\util.py", line
535, in byt
e_compile
  File "C:\Program Files\IronPython 2.6\Lib\py_compile.py", line 138, in
compile

ValueError: unmarshallable object
C:\compile\test\foo-1.0>

----------

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

From report at bugs.python.org  Tue Oct  6 14:03:04 2009
From: report at bugs.python.org (Bheemesh)
Date: Tue, 06 Oct 2009 12:03:04 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1254830584.31.0.933898213819.issue6516@psf.upfronthosting.co.za>


Bheemesh <bheemesh at gmail.com> added the comment:

I just took download of the latest python 2.6.3 which was updated on 2nd
OCT 09, and found that while tarball creation everything looks OK, but
when we un-tar the archive the permissions goes back to the current user
logged in. Can this be set to the user mentioned while archive was created?

----------

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

From report at bugs.python.org  Tue Oct  6 14:28:06 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 06 Oct 2009 12:28:06 +0000
Subject: [issue7068] 2.6.3 does not use specified compiler
In-Reply-To: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
Message-ID: <1254832086.54.0.0182750597193.issue7068@psf.upfronthosting.co.za>


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

Tarek, please commit this fix before 2.6.4rc1 (i.e. asap :)

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

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

From report at bugs.python.org  Tue Oct  6 14:29:49 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 06 Oct 2009 12:29:49 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1254832189.0.0.12602162441.issue6516@psf.upfronthosting.co.za>


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

Hi Bheemesh,

This is a new feature, so it was added in the current trunk that will
become 2.7 and 3.2.

So unfortunately, you can't have it in any 2.6 release.

A workaround is to create your own sdist command, that includes the
changes made in 2.7.

----------

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

From report at bugs.python.org  Tue Oct  6 14:36:32 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 06 Oct 2009 12:36:32 +0000
Subject: [issue7068] 2.6.3 does not use specified compiler
In-Reply-To: <1254798725.88.0.648175309715.issue7068@psf.upfronthosting.co.za>
Message-ID: <1254832592.75.0.94761547332.issue7068@psf.upfronthosting.co.za>


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

Done in r75269. Thanks Shun-ichi and Marc-Andr?

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

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

From report at bugs.python.org  Tue Oct  6 14:37:02 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 06 Oct 2009 12:37:02 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1254832622.63.0.757183712155.issue7064@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

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

From report at bugs.python.org  Tue Oct  6 14:39:30 2009
From: report at bugs.python.org (Bheemesh)
Date: Tue, 06 Oct 2009 12:39:30 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1254832189.0.0.12602162441.issue6516@psf.upfronthosting.co.za>
Message-ID: <670534840910060539x4f9855b0ge24987a7254ee834@mail.gmail.com>


Bheemesh <bheemesh at gmail.com> added the comment:

HI Tarek,

Thanks very much for a quick reply here.
since i am new to this , can you help me with sdist command to have the
latest changes?

Best Regards,
Bheemesh

On Tue, Oct 6, 2009 at 5:59 PM, Tarek Ziad?? <report at bugs.python.org> wrote:

>
> Tarek Ziad?? <ziade.tarek at gmail.com> added the comment:
>
> Hi Bheemesh,
>
> This is a new feature, so it was added in the current trunk that will
> become 2.7 and 3.2.
>
> So unfortunately, you can't have it in any 2.6 release.
>
> A workaround is to create your own sdist command, that includes the
> changes made in 2.7.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6516>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________
-------------- next part --------------
HI Tarek,<br><br>Thanks very much for a quick reply here.<br>since i am new to this , can you help me with sdist command to have the latest changes?<br><br>Best Regards,<br>Bheemesh<br><br><br><br><div class="gmail_quote">
On Tue, Oct 6, 2009 at 5:59 PM, Tarek Ziad?? <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Tarek Ziad?? &lt;<a href="mailto:ziade.tarek at gmail.com">ziade.tarek at gmail.com</a>&gt; added the comment:<br>
<br>
Hi Bheemesh,<br>
<br>
This is a new feature, so it was added in the current trunk that will<br>
become 2.7 and 3.2.<br>
<br>
So unfortunately, you can&#39;t have it in any 2.6 release.<br>
<br>
A workaround is to create your own sdist command, that includes the<br>
changes made in 2.7.<br>
<div><div></div><div class="h5"><br>
----------<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6516" target="_blank">http://bugs.python.org/issue6516</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Oct  6 14:53:12 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Oct 2009 12:53:12 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <4AC8F559.5070201@egenix.com>
Message-ID: <d34314100910060552u7096cb8ap3a69b7501a854fd8@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

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

>> Yes but fixing this inconsitency can be done on either side:
>> A - remove the maintainer and maintainer_email
>> B - add the Maintainer and Maintainer-email in the metadata

>> If we don't have a use case, I'd go for A/
>
> Having a maintainer for a package is not at all uncommon.
>
> Whether you put that maintainer into a separate field or not
> is really a mix of respect/taste/culture.

Please, be specific. PyPi maintainer or trac-plugin package maintainer
or debian package maintainer? Which should be mentioned in debian
package for a trac plugin uploaded to PyPi for easy_install?

> I'd go for B, since we already have the maintainer setup()
> variable and just need to add the missing meta-data field.
>
> Whether this gets used or not is up to 3rd party code
> using the meta-data to decide and not really a distutils
> question.

Is distutils format extensible? Can you create example of extending
distutils format using this maintainer use case, so that every project
can add their own maintainer fields if they need them? If it is
impossible then I suggest to stop this discussion and start planning
extensible distutils2 format with setup2.py and other2 files.

----------

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

From report at bugs.python.org  Tue Oct  6 15:04:26 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Oct 2009 13:04:26 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <d34314100910060552u7096cb8ap3a69b7501a854fd8@mail.gmail.com>
Message-ID: <4ACB4057.1020000@egenix.com>


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

anatoly techtonik wrote:
> 
> anatoly techtonik <techtonik at gmail.com> added the comment:
> 
>>> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
>>> Yes but fixing this inconsitency can be done on either side:
>>> A - remove the maintainer and maintainer_email
>>> B - add the Maintainer and Maintainer-email in the metadata
> 
>>> If we don't have a use case, I'd go for A/
>>
>> Having a maintainer for a package is not at all uncommon.
>>
>> Whether you put that maintainer into a separate field or not
>> is really a mix of respect/taste/culture.
> 
> Please, be specific. PyPi maintainer or trac-plugin package maintainer
> or debian package maintainer? Which should be mentioned in debian
> package for a trac plugin uploaded to PyPi for easy_install?

The maintainer of the plugin.

>> I'd go for B, since we already have the maintainer setup()
>> variable and just need to add the missing meta-data field.
>>
>> Whether this gets used or not is up to 3rd party code
>> using the meta-data to decide and not really a distutils
>> question.
> 
> Is distutils format extensible? Can you create example of extending
> distutils format using this maintainer use case, so that every project
> can add their own maintainer fields if they need them? If it is
> impossible then I suggest to stop this discussion and start planning
> extensible distutils2 format with setup2.py and other2 files.

The meta-data format is versioned, so it's well possible to
add new fields to it or make changes in core distutils.

It's even possible to extend if in custom setup scripts,
provided you know your way around in distutils. Have a
look at dist.py. You'll need to write a Distribution sub-class
and register this via the distclass setup() parameter.

----------

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

From report at bugs.python.org  Tue Oct  6 15:50:37 2009
From: report at bugs.python.org (Eduardo Aguiar)
Date: Tue, 06 Oct 2009 13:50:37 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254837037.95.0.883176840025.issue5395@psf.upfronthosting.co.za>


Eduardo Aguiar <aguiar at users.sourceforge.net> added the comment:

Another try. I have opened a file for writing, and have tried to read
from it:

>>> fp = open ('xxx', 'w')
>>> fp.read ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

----------

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

From report at bugs.python.org  Tue Oct  6 16:07:45 2009
From: report at bugs.python.org (Naoki INADA)
Date: Tue, 06 Oct 2009 14:07:45 +0000
Subject: [issue7072] isspace(0xa0) is true on Mac OS X
In-Reply-To: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
Message-ID: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>


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

Old FreeBSD's libc has a bug relate to utf-8 locale and Python have 
patch for it: http://svn.python.org/view/python/trunk/Include/pyport.h?
view=diff&pathrev=43219&r1=36792&r2=36793

This bug appears in Mac OS X again. This test fails:
>>> s = '\xa0'
>>> assert s.strip() == s
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> assert s.strip() == s

So above patch should be enabled for Mac OS X.

----------
messages: 93650
nosy: naoki
severity: normal
status: open
title: isspace(0xa0) is true on Mac OS X
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct  6 17:07:46 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Oct 2009 15:07:46 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <4ACB4057.1020000@egenix.com>
Message-ID: <d34314100910060807o583f94a9yf107fe308502daed@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>>
>> Please, be specific. PyPi maintainer or trac-plugin package maintainer
>> or debian package maintainer? Which should be mentioned in debian
>> package for a trac plugin uploaded to PyPi for easy_install?
>
> The maintainer of the plugin.
>

So, the maintainer of the plugin is mentioned in setup.py, but this
field is also used in PyPi and the person who maintains it there wants
some attribution. Should this person change maintainer field to
himself?

>> Is distutils format extensible? Can you create example of extending
>> distutils format using this maintainer use case, so that every project
>> can add their own maintainer fields if they need them? If it is
>> impossible then I suggest to stop this discussion and start planning
>> extensible distutils2 format with setup2.py and other2 files.
>
> The meta-data format is versioned, so it's well possible to
> add new fields to it or make changes in core distutils.

No, that's not the way. Suppose we have three independent external
frameworks that use setup.py files for deploying their
plugins/components. All three need to extend distutils format. Which
version should they choose? What if official distutils release will
decide to use this version? Will other tools parse all these new
versions correctly?

> It's even possible to extend if in custom setup scripts,
> provided you know your way around in distutils. Have a
> look at dist.py. You'll need to write a Distribution sub-class
> and register this via the distclass setup() parameter.

As you may see I definitely do not know my way in distutils. =) Can
you show the example of extending setup.py with pypi_maintainers
field, that includes emails that should be granted maintainer rights
by PyPi automatically on setup.py submission? It is not that I am
challenging you to something - I just want to say that there are not
many people who knows distutils like you to create the best solution
for this user story. Even if it can be a tedious task the outcome is
really important for further distutils usability improvement.

----------

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

From report at bugs.python.org  Tue Oct  6 17:09:21 2009
From: report at bugs.python.org (Jan Hosang)
Date: Tue, 06 Oct 2009 15:09:21 +0000
Subject: [issue5395] array.fromfile not checking I/O errors
In-Reply-To: <1235845824.28.0.0746931050705.issue5395@psf.upfronthosting.co.za>
Message-ID: <1254841761.82.0.621007319828.issue5395@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

Thanks Aduardo! (I could have sworn I tried that.) I changed the test to 
reading from a file in 'wb' mode, which raised a EOFError before and now 
raises IOErrors.

----------
Added file: http://bugs.python.org/file15055/array_ioerror.patch

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

From report at bugs.python.org  Tue Oct  6 17:20:17 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Oct 2009 15:20:17 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1254842417.98.0.960293600586.issue6670@psf.upfronthosting.co.za>


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

To fix this problem is enough to add an !important to the margin: 0;
rule in the @media print {} at the end of basic.css (line 408).

I'll try to explain why the !important is necessary.
In default.css @import url("basic.css"); (correctly) appears at the
beginning, and imports the rules from basic.css, including the @media
print {}. A few lines later, in default.css, there's the rule
div.bodywrapper { margin: 0 0 0 230px; }, and with no @media specified
it defaults on 'all'.

In default.css we then end up with something equivalent to:

/* This is defined in basic.css and imported
   at the beginning of default.css */
@media print {
    /* some rules omitted for clarity */
    div.bodywrapper { margin: 0; }
}

/* This is defined later in default.css */
@media all { /* This is implicit */
    div.bodywrapper { margin: 0 0 0 230px; }
}

When the file is printed both the rules are applied, because 'all' also
includes 'print'.
Since both the media have the same priority (i.e. the specific @media
print does NOT have higher priority than the implicit @media all) and
both the rules have the same priority too, the latter wins.
The !important is then needed to raise the priority of the first rule.

Note that adding the !important is not a really good solution IMHO: the
problem could appear again if other rules with the same priority of the
ones in @media print {} are specified elsewhere.
A good solution would be to move the print rules after the normal ones,
so in case the print media is used these rules will have higher priority.
The @import can only appear at the beginning of a file so the two
possible solutions are:

1) put the rules with media all in, for example, all.css and the ones
with media print in print.css and then, in default.css, write only:
@import url('all.css');
@import url('print.css') print;

2) like 1) but importing the print.css separately using <link> in the
html pages:
<link href="default.css" type="text/css" rel="stylesheet">
<link href="print.css" type="text/css" rel="stylesheet" media="print">

A third solution might be to specify the media of the normal rules to
'screen', but some rules are probably common to both the media.

More information here: http://www.w3.org/TR/CSS2/cascade.html

----------

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

From report at bugs.python.org  Tue Oct  6 17:24:08 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Oct 2009 15:24:08 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <d34314100910060807o583f94a9yf107fe308502daed@mail.gmail.com>
Message-ID: <4ACB6113.9090605@egenix.com>


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

anatoly techtonik wrote:
> 
> anatoly techtonik <techtonik at gmail.com> added the comment:
> 
> On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>>>
>>> Please, be specific. PyPi maintainer or trac-plugin package maintainer
>>> or debian package maintainer? Which should be mentioned in debian
>>> package for a trac plugin uploaded to PyPi for easy_install?
>>
>> The maintainer of the plugin.
>>
> 
> So, the maintainer of the plugin is mentioned in setup.py, but this
> field is also used in PyPi and the person who maintains it there wants
> some attribution. Should this person change maintainer field to
> himself?

We have a long description field for such things. If you look on PyPI
that field is even being used for complete documentation of a package,
so adding a note about some extra maintainer is certainly within
range.

>>> Is distutils format extensible? Can you create example of extending
>>> distutils format using this maintainer use case, so that every project
>>> can add their own maintainer fields if they need them? If it is
>>> impossible then I suggest to stop this discussion and start planning
>>> extensible distutils2 format with setup2.py and other2 files.
>>
>> The meta-data format is versioned, so it's well possible to
>> add new fields to it or make changes in core distutils.
> 
> No, that's not the way. Suppose we have three independent external
> frameworks that use setup.py files for deploying their
> plugins/components. All three need to extend distutils format. Which
> version should they choose? What if official distutils release will
> decide to use this version? Will other tools parse all these new
> versions correctly?

There's only one official distutils meta-format: that of core distutils.

Up until now, we've only added new fields, so old tools will
continue to work (but not know about the new fields).

>> It's even possible to extend if in custom setup scripts,
>> provided you know your way around in distutils. Have a
>> look at dist.py. You'll need to write a Distribution sub-class
>> and register this via the distclass setup() parameter.
> 
> As you may see I definitely do not know my way in distutils. =) Can
> you show the example of extending setup.py with pypi_maintainers
> field, that includes emails that should be granted maintainer rights
> by PyPi automatically on setup.py submission? It is not that I am
> challenging you to something - I just want to say that there are not
> many people who knows distutils like you to create the best solution
> for this user story. Even if it can be a tedious task the outcome is
> really important for further distutils usability improvement.

I don't have time for such challenges. Like I said: it's possible
and easy to do, but that doesn't necessarily mean that adding
custom fields to the meta-file format should be encouraged.

I also don't think that distutils meta data should be used
for automatic administration of tools such as PyPI. It has
purely informational character and helps in searching or
browsing Python packages. Nothing more.

----------

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

From report at bugs.python.org  Tue Oct  6 19:14:00 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Oct 2009 17:14:00 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1254849240.87.0.100525366522.issue7029@psf.upfronthosting.co.za>


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

Here is an updated patch with the superfluous timing function removed.
Please advise me on how you "don't like the implementation"

I'm also considering adding a '--quiet' flag that causes it to only emit 
the 'total' line.  This is useful for automated testing of builds.  Any 
thoughts about that?

----------

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

From report at bugs.python.org  Tue Oct  6 19:14:29 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Oct 2009 17:14:29 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1254849269.22.0.281330106697.issue7029@psf.upfronthosting.co.za>


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

And here is the actual patch.

----------
Added file: http://bugs.python.org/file15056/pybench.patch

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

From report at bugs.python.org  Tue Oct  6 20:35:27 2009
From: report at bugs.python.org (Andrey Petrov)
Date: Tue, 06 Oct 2009 18:35:27 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1254854127.38.0.214468716254.issue3244@psf.upfronthosting.co.za>


Andrey Petrov <andrey.petrov at shazow.net> added the comment:

Once upon a time I wrote a library that did some of this among other things:

http://code.google.com/p/urllib3/

Or specifically:
http://code.google.com/p/urllib3/source/browse/trunk/urllib3/filepost.py

The code was borrowed from some of the recipes mentioned, but cleaned up
and adjusted a bit. Feel free to use it or borrow from it in any way you
like.

----------
nosy: +shazow

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

From report at bugs.python.org  Tue Oct  6 22:07:48 2009
From: report at bugs.python.org (Adam Nelson)
Date: Tue, 06 Oct 2009 20:07:48 +0000
Subject: [issue918368] urllib doesn't correct server returned urls
Message-ID: <1254859668.61.0.402697866918.issue918368@psf.upfronthosting.co.za>


Adam Nelson <adam at varud.com> added the comment:

This seems a bit serious for inclusion in 2.7 IMHO.  urllib is used in all 
sorts of hackish ways in the wild and I really wonder if this is going to 
cause more problems for people than it's worth.  The 3.x series alone 
seems like the best place for this which is addressed by issue 1153027.

----------
nosy: +AdamN

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

From report at bugs.python.org  Tue Oct  6 22:41:40 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Oct 2009 20:41:40 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254861700.66.0.306140310588.issue5127@psf.upfronthosting.co.za>


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

It's not as easy as that.

The functions for case conversion are used in a way that assumes they
never fail (and indeed, the existing functions cannot fail).

What we can do is change the input parameter to Py_UCS4, but not the
Py_UNICODE output parameter, since that would cause lots of compiler
warnings and implicit truncation on UCS2 builds, which would be a pretty
disruptive change.

However, this change would not really help anyone if there are no
mappings from BMP to non-BMP or vice-versa, so I'm not sure whether this
whole exercise is worth the effort.

It appears to be better to just leave the case mapping APIs unchanged -
or am I missing something ?

The situation is different for the various Py_UNICODE_IS*() APIs: for
these we can change the input parameter to Py_UCS4, remove the name
mangling and add UCS2 helper functions to maintain API compatibility on
UCS2 builds.

----------

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

From report at bugs.python.org  Tue Oct  6 22:51:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 06 Oct 2009 20:51:24 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1254862284.69.0.735675414281.issue7069@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Tests added.

----------
Added file: http://bugs.python.org/file15057/inspect.diff

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

From report at bugs.python.org  Tue Oct  6 22:51:35 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 06 Oct 2009 20:51:35 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1254862295.57.0.264842518971.issue7069@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file15052/inspect.diff

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

From report at bugs.python.org  Tue Oct  6 22:57:04 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Oct 2009 20:57:04 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254849240.87.0.100525366522.issue7029@psf.upfronthosting.co.za>
Message-ID: <4ACBAF1D.7060801@egenix.com>


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

Kristj?n Valur J?nsson wrote:
> 
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
> 
> Here is an updated patch with the superfluous timing function removed.
> Please advise me on how you "don't like the implementation"

The reporting methods are a complete mess (not your patch, my code).
They need a rewrite and then I can apply the extra gross output.

Something that would need to change is the .stat() patch: why
didn't you just add 3 new fields to the tuple instead of using
a list with 2 tuples ?

In any case, please don't invest too much time into this. I'm going
to rewrite the statistics part anyway and can then add the new
gross values while I'm at it.

> I'm also considering adding a '--quiet' flag that causes it to only emit 
> the 'total' line.  This is useful for automated testing of builds.  Any 
> thoughts about that?

Could be useful, yes.

----------

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

From report at bugs.python.org  Tue Oct  6 23:27:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Oct 2009 21:27:48 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254864468.25.0.484365983959.issue5127@psf.upfronthosting.co.za>


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

> that would cause lots of compiler
> warnings and implicit truncation on UCS2 builds

Unfortunately, there is no such warning, or the initial problem we are trying 
to solve would have been spotted by such a warning (unicode_repr() calls 
Py_UNICODE_ISPRINTABLE() with a Py_UCS4 argument).

gcc has a -Wconversion flag, (which I tried today on python) but it is far too 
verbose before version 4.3, and this newer version still has some false 
positives. http://gcc.gnu.org/wiki/NewWconversion

But the most important thing is that implicit truncation on UCS2 builds is what 
happens already! The patch does not solve it, but at least it yields sensible 
results to wary code.
Or can you imagine some (somewhat working) code which behavior will be worse 
after the change?

----------

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

From report at bugs.python.org  Tue Oct  6 23:35:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Oct 2009 21:35:56 +0000
Subject: [issue1571184] Generate numeric/space/linebreak from Unicode database.
Message-ID: <1254864956.4.0.773640468596.issue1571184@psf.upfronthosting.co.za>


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

Patch applied with r75272.
Merged to py3k, adapted and regenerated files with r75274.

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

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

From report at bugs.python.org  Tue Oct  6 23:52:37 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 06 Oct 2009 21:52:37 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1254865957.13.0.816224421526.issue6670@psf.upfronthosting.co.za>


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

This request really does need a patch+tests+doc changes - I don't know if 
anyone with +commit has the time to distill the various implementations 
and generate something.

----------
nosy: +jnoller

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

From report at bugs.python.org  Tue Oct  6 23:52:48 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 06 Oct 2009 21:52:48 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1254865968.33.0.939548257388.issue6670@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------

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

From report at bugs.python.org  Tue Oct  6 23:53:12 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 06 Oct 2009 21:53:12 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1254865992.12.0.452774874981.issue6670@psf.upfronthosting.co.za>


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

I posted to the wrong bug, apologies

----------

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

From report at bugs.python.org  Tue Oct  6 23:53:21 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 06 Oct 2009 21:53:21 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1254866001.13.0.360890212443.issue3244@psf.upfronthosting.co.za>


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

This request really does need a patch+tests+doc changes - I don't know if 
anyone with +commit has the time to distill the various implementations 
and generate something.

----------
nosy: +jnoller

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

From report at bugs.python.org  Wed Oct  7 00:02:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Oct 2009 22:02:28 +0000
Subject: [issue5127] UnicodeEncodeError - I can't even see license
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1254866548.55.0.64595880875.issue5127@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file15058/unicodectype_ucs4_3.patch

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

From report at bugs.python.org  Wed Oct  7 00:46:26 2009
From: report at bugs.python.org (Jose Antonio Martin H)
Date: Tue, 06 Oct 2009 22:46:26 +0000
Subject: [issue7073] Python 2.6.3 final windows installer installs a release
	candidate
In-Reply-To: <1254869186.46.0.379870800364.issue7073@psf.upfronthosting.co.za>
Message-ID: <1254869186.46.0.379870800364.issue7073@psf.upfronthosting.co.za>


New submission from Jose Antonio Martin H <jamartinh at fdi.ucm.es>:

Python 2.6.3 (r263rc1:75186, Oct  2 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)] on win32

That is the python that is installed with the python 2.6.3 installer.

----------
components: Installation
messages: 93667
nosy: jamartinh
severity: normal
status: open
title: Python 2.6.3 final  windows installer installs a release candidate
versions: Python 2.6

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

From report at bugs.python.org  Wed Oct  7 00:52:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Oct 2009 22:52:07 +0000
Subject: [issue7073] Python 2.6.3 final windows installer installs a release
	candidate
In-Reply-To: <1254869186.46.0.379870800364.issue7073@psf.upfronthosting.co.za>
Message-ID: <1254869527.3.0.393878331799.issue7073@psf.upfronthosting.co.za>


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

This is a known issue, 2.6.4 will be out soon. See
http://mail.python.org/pipermail/python-committers/2009-October/000648.html

----------
nosy: +ezio.melotti
resolution:  -> later
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Oct  7 01:39:36 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Oct 2009 23:39:36 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>


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

Attached file run from IDLE edit window with 3.1, winxp works fine--
turtle moves in response to cursor keys-- if quit soon enough.
But after about 1000 key repeats, pythonw crashes with standard MSVC++
runtime error window, pythonw error window, and IDLE shell window
trackback ending with "RuntimeError: maximum recursion depth exceeded
while calling a Python object". The full traceback in appended to the file.

Disabling the undo buffer did not solve the problem.

Running the file from regular interpreter with
>>>exec(open(filename,'r').read())

gave essentially same result -- same traceback with slightly different
associated messages, so it is not an IDLE problem.

The demo/test at the bottem of turtle.py works fine -- but it does not
run as long.

I do not see the recursion, but calling the configuration merge with
every movement seems fishy.

----------
components: Library (Lib)
files: turtlecrash.py
messages: 93669
nosy: tjreedy
severity: normal
status: open
title: Turtle module crashes python
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15059/turtlecrash.py

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

From report at bugs.python.org  Wed Oct  7 01:40:59 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Oct 2009 23:40:59 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1254872459.73.0.782706903379.issue7074@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file15059/turtlecrash.py

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

From report at bugs.python.org  Wed Oct  7 01:41:30 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Oct 2009 23:41:30 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1254872490.85.0.658503770612.issue7074@psf.upfronthosting.co.za>


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

resubmitting file

----------
Added file: http://bugs.python.org/file15060/turtlecrash.py

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

From report at bugs.python.org  Wed Oct  7 03:34:53 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Oct 2009 01:34:53 +0000
Subject: [issue918368] urllib doesn't correct server returned urls
Message-ID: <1254879293.6.0.699144762934.issue918368@psf.upfronthosting.co.za>


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

AdamN, did you specifically come across a scenario which broke due to
this change? I can understand your concern, in general. The
'non-breaking' existing tests is the one of confidence factor we have in
introducing the changes.

----------

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

From report at bugs.python.org  Wed Oct  7 04:09:24 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Wed, 07 Oct 2009 02:09:24 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1254881364.09.0.41577991684.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


Removed file: http://bugs.python.org/file14876/issue6845.patch

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

From report at bugs.python.org  Wed Oct  7 04:21:46 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 07 Oct 2009 02:21:46 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1254882106.85.0.453954415721.issue3563@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

Attached a patch that implements more thoroughly what appears to be the
intended behavior.

----------
nosy: +joe.amenta
Added file: http://bugs.python.org/file15061/fix_idioms.patch

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

From report at bugs.python.org  Wed Oct  7 04:23:05 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 07 Oct 2009 02:23:05 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1254882185.73.0.0809001833021.issue3563@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15061/fix_idioms.patch

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

From report at bugs.python.org  Wed Oct  7 04:23:42 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 07 Oct 2009 02:23:42 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1254882222.05.0.822876572815.issue3563@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

Missed a paren in the last one... re-uploading it.

----------
Added file: http://bugs.python.org/file15062/fix_idioms.patch

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

From report at bugs.python.org  Wed Oct  7 05:28:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2009 03:28:23 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1254886103.06.0.311198289685.issue3563@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Oct  7 05:46:11 2009
From: report at bugs.python.org (Chu-Cheng)
Date: Wed, 07 Oct 2009 03:46:11 +0000
Subject: [issue7075] Bug while put a set on a dict
In-Reply-To: <1254887171.46.0.861154287703.issue7075@psf.upfronthosting.co.za>
Message-ID: <1254887171.46.0.861154287703.issue7075@psf.upfronthosting.co.za>


New submission from Chu-Cheng <chucheng at gmail.com>:

>>> x={1:{1}}
>>> x[1] = (x.get(1).add(2))
>>> x
{1: None}

But...
>>> x={1:{1}}
>>> o = x.get(1)
>>> o.add(2)
>>> o
{1, 2}
>>> x[1] = o
>>> x
{1: {1, 2}}

----------
components: None
messages: 93674
nosy: chucheng
severity: normal
status: open
title: Bug while put a set on a dict
versions: Python 3.1

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

From report at bugs.python.org  Wed Oct  7 06:06:00 2009
From: report at bugs.python.org (Chu-Cheng)
Date: Wed, 07 Oct 2009 04:06:00 +0000
Subject: [issue7075] Bug while put a set on a dict
In-Reply-To: <1254887171.46.0.861154287703.issue7075@psf.upfronthosting.co.za>
Message-ID: <1254888360.76.0.907557415432.issue7075@psf.upfronthosting.co.za>


Chu-Cheng <chucheng at gmail.com> added the comment:

my fault, I know what is the difference now :) sorry for bugging

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

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

From report at bugs.python.org  Wed Oct  7 06:19:50 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 07 Oct 2009 04:19:50 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1254889190.96.0.556026984886.issue6717@psf.upfronthosting.co.za>


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

For anyone trying this on another system: you must specifically click on
and drag the mouse/turtle graphic.

Running from IDLE edit, I get no traceback in the Shell Window, unlike
with the script I attached to #7074 and now here. While I am closing the
latter as probably due to the same cause, it does act differently:
adding the 'speed(0)' command present in dragbug.py appears to have
fixed the problem with turtlecrash.py.

Rewriting dragbug to use tkinter canvas directly would determine whether
the turtle module is a factor. The change of behavior with turtlecrash
with the speed command suggests to me that it might be.

----------
nosy: +tjreedy
Added file: http://bugs.python.org/file15063/turtlecrash.py

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

From report at bugs.python.org  Wed Oct  7 07:47:04 2009
From: report at bugs.python.org (Jan Hosang)
Date: Wed, 07 Oct 2009 05:47:04 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1254894424.53.0.82160996448.issue7069@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I changed the patch so it does not introduce new dependencies and fails 
before the patch of isabstract().

----------
Added file: http://bugs.python.org/file15064/inspect.diff

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

From report at bugs.python.org  Wed Oct  7 07:48:11 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Wed, 07 Oct 2009 05:48:11 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>


New submission from Shawn Ligocki <sligocki at gmail.com>:

I did not notice the existence of random.SystemRandom until after I had
implemented my own version. I thought it would be nice to mention it in
the opening section. I've added a tiny note about random.SystemRandom.
What do you guys think, feel free to reword it, I just think that it
should be mentioned.

http://docs.python.org/library/random.html

----------
assignee: georg.brandl
components: Documentation
files: random.patch
keywords: patch
messages: 93678
nosy: georg.brandl, sligocki
severity: normal
status: open
title: Documentation add note about SystemRandom
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15065/random.patch

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

From report at bugs.python.org  Wed Oct  7 08:14:01 2009
From: report at bugs.python.org (Jan Hosang)
Date: Wed, 07 Oct 2009 06:14:01 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254896041.71.0.555864522161.issue7076@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

I think non-determinism is more then os.urandom can deliver. As far as I 
know the OS still does deterministic calculations, though they are maybe 
less obvious. Maybe call it "safer, OS dependent"?

----------
nosy: +chuck

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

From report at bugs.python.org  Wed Oct  7 08:55:53 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Oct 2009 06:55:53 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254898553.32.0.444070872067.issue7076@psf.upfronthosting.co.za>


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

FWIW, the docs for os.urandom() state:

"""Return a string of n random bytes suitable for cryptographic use.

This function returns random bytes from an OS-specific randomness
source. The returned data should be unpredictable enough for
cryptographic applications, though its exact quality depends on the OS
implementation. On a UNIX-like system this will query /dev/urandom, and
on Windows it will use CryptGenRandom.
"""

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

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

From report at bugs.python.org  Wed Oct  7 08:56:01 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Oct 2009 06:56:01 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254898561.46.0.311769053946.issue7076@psf.upfronthosting.co.za>


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


----------
assignee: georg.brandl -> rhettinger

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

From report at bugs.python.org  Wed Oct  7 10:24:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Oct 2009 08:24:21 +0000
Subject: [issue6773] subprocess issue on Win 7 x64
In-Reply-To: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>
Message-ID: <1254903861.69.0.179075015351.issue6773@psf.upfronthosting.co.za>


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

I cannot reproduce it on Win7 32bit (OS Name: Microsoft Windows 7
Enterprise; OS Version: 6.1.7600 N/A Build 7600) with Python 2.6.3rc1.
Attached there's the file I used (a slightly different version of what
you posted, your version worked too), this is the output I got:

cmd>python issue6773.py
"hello from myProcess"

cmd>

----------
nosy: +ezio.melotti
priority:  -> normal
Added file: http://bugs.python.org/file15066/issue6773.py

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

From report at bugs.python.org  Wed Oct  7 10:27:05 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Wed, 07 Oct 2009 08:27:05 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254904025.11.0.39604226496.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Oh, urandom is almost always non-deterministic. It mixes completely
random bits from hardware sources with its pseudo-random number state.
The more random bits it gets from hardware, the less predictable its
output is. However, as long as it's getting any random bits, it's output
is not deterministic (because it's based on some random information).

But perhaps there is better wording that conveys the power of the
urandom source?

----------

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

From report at bugs.python.org  Wed Oct  7 10:45:32 2009
From: report at bugs.python.org (Jan Hosang)
Date: Wed, 07 Oct 2009 08:45:32 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254905132.64.0.738827978113.issue7076@psf.upfronthosting.co.za>


Jan Hosang <jan.hosang at gmail.com> added the comment:

Maybe os.urandom is "more random" than the module random in the sense that 
it is harder to figure out what comes next, but still deterministic. The 
readings from the hardware are random and you usually don't know them, yet 
what comes out of urandom is determined by what urandom reads from the 
hardware and its state. I just want to warn not to drop wrong terms.

----------

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

From report at bugs.python.org  Wed Oct  7 11:08:55 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Wed, 07 Oct 2009 09:08:55 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254906535.44.0.0885281928808.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Ah, sorry for the misunderstanding. I agree, better not to mislead. 

Perhaps we should side with the urandom documentation and say that it is
a cryptographically secure random number generator with no accessible state?

----------

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

From report at bugs.python.org  Wed Oct  7 11:26:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 09:26:38 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254907598.75.0.760504668882.issue7048@psf.upfronthosting.co.za>


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

(Stefan emailed Mike Cowlishaw about this:  thanks, Stefan!)

Mike's initial response suggests that we *should* be rounding the result
here.  That is, decNumber and decimal.py are both in error, and Stefan's
interpretation is correct.

----------
assignee:  -> mark.dickinson
components: +Library (Lib)
priority:  -> high
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Oct  7 11:33:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 09:33:01 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254907981.68.0.982645204015.issue7048@psf.upfronthosting.co.za>


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

Attaching additional testcases from Mike Cowlishaw.

----------
Added file: http://bugs.python.org/file15067/logb_additional.decTest

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

From report at bugs.python.org  Wed Oct  7 11:35:30 2009
From: report at bugs.python.org (chuck)
Date: Wed, 07 Oct 2009 09:35:30 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254908130.41.0.75684863179.issue7076@psf.upfronthosting.co.za>


chuck <jan.hosang at gmail.com> added the comment:

Depends on how verbose we want to be. It should say why one might want to 
use urandom() instead of random (if you decide you are interested you can 
still look up the documentation). I think it would be nice to say why 
random does not use urandom if urandom is better, so you end up with a 
very short pro/con of urandom, which should be appropriate for users who 
are seeking information on getting random numbers.

Unfortunately I don't know enough about random. I guess it's a 
speed/security tradeoff?

----------

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

From report at bugs.python.org  Wed Oct  7 12:18:31 2009
From: report at bugs.python.org (Piotr Foltyn)
Date: Wed, 07 Oct 2009 10:18:31 +0000
Subject: [issue6773] subprocess issue on Win 7 x64
In-Reply-To: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>
Message-ID: <1254910711.26.0.473514443331.issue6773@psf.upfronthosting.co.za>


Piotr Foltyn <piotr.foltyn at displaylink.com> added the comment:

I cannot reproduce it on Windows 7 x64 Ultimate either.
sys.getwindowsversion() -> (6, 1, 7600, 2, '')

Probably this bug was in Win7 RC and not in python. Thanks for your time. 
Closing.

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

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

From report at bugs.python.org  Wed Oct  7 13:55:34 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Oct 2009 11:55:34 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1254916534.89.0.570579912111.issue6978@psf.upfronthosting.co.za>


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

your patch is no more a diff file (the 'previous' file is empty)

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

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

From report at bugs.python.org  Wed Oct  7 14:02:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Oct 2009 12:02:58 +0000
Subject: [issue6962] traceback.format_exception_only does not return
	SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1254916978.95.0.240555201771.issue6962@psf.upfronthosting.co.za>


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

You did not attach any patch. But anyway this has already been fixed by
issue1326077.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> traceback.py formats SyntaxError differently

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

From report at bugs.python.org  Wed Oct  7 14:26:10 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 07 Oct 2009 12:26:10 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1254918370.26.0.180478064417.issue7051@psf.upfronthosting.co.za>


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

Mark's really the expert here, so I trust his description. Is his
description layman-speak enough for the docs?

----------

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

From report at bugs.python.org  Wed Oct  7 14:30:54 2009
From: report at bugs.python.org (Kees Bos)
Date: Wed, 07 Oct 2009 12:30:54 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1254918654.95.0.819169013593.issue6978@psf.upfronthosting.co.za>


Kees Bos <k.bos at zx.nl> added the comment:

Sorry. Renamed .bak to .orig ...
Here's the patch compiler/transformer.py (against python 2.5)

----------
Added file: http://bugs.python.org/file15068/transformer.py.patch

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

From report at bugs.python.org  Wed Oct  7 14:42:38 2009
From: report at bugs.python.org (Robert Szefler)
Date: Wed, 07 Oct 2009 12:42:38 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>


New submission from Robert Szefler <robert.szefler at redefine.pl>:

Trying to .emit() a Unicode string causes an awkward exception to be thrown:

Traceback (most recent call last):
  File "/usr/lib/python2.5/logging/handlers.py", line 672, in emit
    self.socket.sendto(msg, self.address)
TypeError: sendto() takes exactly 3 arguments (2 given)

The issue is fixed simply by adding some sort of encoding coercion
before the sendto, for example:

if type(msg)==unicode: msg=msg.encode('utf-8')

----------
components: Library (Lib)
messages: 93694
nosy: rszefler
severity: normal
status: open
title: SysLogHandler can't handle Unicode
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct  7 14:46:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 12:46:37 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1254919597.91.0.282653292157.issue7051@psf.upfronthosting.co.za>


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

That's amusing.  The moment I submitted the comment above I remember
thinking  'Hmm.  I could have explained that better.'

I'll try to come up with a doc patch.

Stealing the issue from Eric.

----------
assignee: eric.smith -> mark.dickinson

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

From report at bugs.python.org  Wed Oct  7 15:11:44 2009
From: report at bugs.python.org (brimac)
Date: Wed, 07 Oct 2009 13:11:44 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1254842417.98.0.960293600586.issue6670@psf.upfronthosting.co.za>
Message-ID: <9bd6f93d0910070611x70eaac7dsd2b167769fee3f4a@mail.gmail.com>


brimac <brimac at bcs.org> added the comment:

Hi Ezio

Many thanks for all your effort with this problem.
Thanks also for the full explanation and link.
I'm not sure what happens now. Will somebody fix it?
I think it's important for Python's image because
it might be the first page a new user tries to print.

brimac

2009/10/6 Ezio Melotti <report at bugs.python.org>

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> To fix this problem is enough to add an !important to the margin: 0;
> rule in the @media print {} at the end of basic.css (line 408).
>
> I'll try to explain why the !important is necessary.
> In default.css @import url("basic.css"); (correctly) appears at the
> beginning, and imports the rules from basic.css, including the @media
> print {}. A few lines later, in default.css, there's the rule
> div.bodywrapper { margin: 0 0 0 230px; }, and with no @media specified
> it defaults on 'all'.
>
> In default.css we then end up with something equivalent to:
>
> /* This is defined in basic.css and imported
>   at the beginning of default.css */
> @media print {
>    /* some rules omitted for clarity */
>    div.bodywrapper { margin: 0; }
> }
>
> /* This is defined later in default.css */
> @media all { /* This is implicit */
>    div.bodywrapper { margin: 0 0 0 230px; }
> }
>
> When the file is printed both the rules are applied, because 'all' also
> includes 'print'.
> Since both the media have the same priority (i.e. the specific @media
> print does NOT have higher priority than the implicit @media all) and
> both the rules have the same priority too, the latter wins.
> The !important is then needed to raise the priority of the first rule.
>
> Note that adding the !important is not a really good solution IMHO: the
> problem could appear again if other rules with the same priority of the
> ones in @media print {} are specified elsewhere.
> A good solution would be to move the print rules after the normal ones,
> so in case the print media is used these rules will have higher priority.
> The @import can only appear at the beginning of a file so the two
> possible solutions are:
>
> 1) put the rules with media all in, for example, all.css and the ones
> with media print in print.css and then, in default.css, write only:
> @import url('all.css');
> @import url('print.css') print;
>
> 2) like 1) but importing the print.css separately using <link> in the
> html pages:
> <link href="default.css" type="text/css" rel="stylesheet">
> <link href="print.css" type="text/css" rel="stylesheet" media="print">
>
> A third solution might be to specify the media of the normal rules to
> 'screen', but some rules are probably common to both the media.
>
> More information here: http://www.w3.org/TR/CSS2/cascade.html
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6670>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________
-------------- next part --------------
Hi Ezio<br><br>Many thanks for all your effort with this problem.<br>Thanks also for the full explanation and link.<br>I&#39;m not sure what happens now. Will somebody fix it?<br>I think it&#39;s important for Python&#39;s image because<br>
it might be the first page a new user tries to print.<br><br>brimac<br><br><br><div class="gmail_quote">2009/10/6 Ezio Melotti <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
Ezio Melotti &lt;<a href="mailto:ezio.melotti at gmail.com">ezio.melotti at gmail.com</a>&gt; added the comment:<br>
<br>
</div>To fix this problem is enough to add an !important to the margin: 0;<br>
rule in the @media print {} at the end of basic.css (line 408).<br>
<br>
I&#39;ll try to explain why the !important is necessary.<br>
In default.css @import url(&quot;basic.css&quot;); (correctly) appears at the<br>
beginning, and imports the rules from basic.css, including the @media<br>
print {}. A few lines later, in default.css, there&#39;s the rule<br>
div.bodywrapper { margin: 0 0 0 230px; }, and with no @media specified<br>
it defaults on &#39;all&#39;.<br>
<br>
In default.css we then end up with something equivalent to:<br>
<br>
/* This is defined in basic.css and imported<br>
 ?? at the beginning of default.css */<br>
@media print {<br>
 ?? ??/* some rules omitted for clarity */<br>
 ?? ??div.bodywrapper { margin: 0; }<br>
}<br>
<br>
/* This is defined later in default.css */<br>
@media all { /* This is implicit */<br>
 ?? ??div.bodywrapper { margin: 0 0 0 230px; }<br>
}<br>
<br>
When the file is printed both the rules are applied, because &#39;all&#39; also<br>
includes &#39;print&#39;.<br>
Since both the media have the same priority (i.e. the specific @media<br>
print does NOT have higher priority than the implicit @media all) and<br>
both the rules have the same priority too, the latter wins.<br>
The !important is then needed to raise the priority of the first rule.<br>
<br>
Note that adding the !important is not a really good solution IMHO: the<br>
problem could appear again if other rules with the same priority of the<br>
ones in @media print {} are specified elsewhere.<br>
A good solution would be to move the print rules after the normal ones,<br>
so in case the print media is used these rules will have higher priority.<br>
The @import can only appear at the beginning of a file so the two<br>
possible solutions are:<br>
<br>
1) put the rules with media all in, for example, all.css and the ones<br>
with media print in print.css and then, in default.css, write only:<br>
@import url(&#39;all.css&#39;);<br>
@import url(&#39;print.css&#39;) print;<br>
<br>
2) like 1) but importing the print.css separately using &lt;link&gt; in the<br>
html pages:<br>
&lt;link href=&quot;default.css&quot; type=&quot;text/css&quot; rel=&quot;stylesheet&quot;&gt;<br>
&lt;link href=&quot;print.css&quot; type=&quot;text/css&quot; rel=&quot;stylesheet&quot; media=&quot;print&quot;&gt;<br>
<br>
A third solution might be to specify the media of the normal rules to<br>
&#39;screen&#39;, but some rules are probably common to both the media.<br>
<br>
More information here: <a href="http://www.w3.org/TR/CSS2/cascade.html" target="_blank">http://www.w3.org/TR/CSS2/cascade.html</a><br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6670" target="_blank">http://bugs.python.org/issue6670</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Wed Oct  7 15:22:22 2009
From: report at bugs.python.org (Adam Nelson)
Date: Wed, 07 Oct 2009 13:22:22 +0000
Subject: [issue918368] urllib doesn't correct server returned urls
Message-ID: <1254921742.14.0.423322765609.issue918368@psf.upfronthosting.co.za>


Adam Nelson <adam at varud.com> added the comment:

I can't think of too many specific scenarios.  It just seems like a non-
trivial behavior change (or rather, it is trivial but with possibly far 
reaching ramifications).

One issue I see is that the ticket morphed from just dealing with space 
characters to many special characters.  quote_plus() probably would have 
handled the space issue cleanly.

The other issue I'm concerned about is that there is no testing of non-
ascii URLs (or at least I don't see any).

Finally, a netloc like 'www.g oogle.com' would be converted invalidly to 
'www.g%20oogle.com' which would then be forwarded to an actual HTTP 
request.

I can't point to anything too specific - more of just a feeling that 
this ticket is already 5 1/2 years old and maybe things should be left 
as-is and enhancement made only to Python 3.x.  Of course, I'm really 
just a new Python convert so I don't have massive experience here by any 
means.

----------

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

From report at bugs.python.org  Wed Oct  7 16:01:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Oct 2009 14:01:37 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1254924097.23.0.899216769117.issue6670@psf.upfronthosting.co.za>


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

> I'm not sure what happens now. Will somebody fix it?

Now that the problem and the solution are known, Georg will probably fix
it at some point. The "!important" could be used as a temporary
workaround (e.g. for 2.6.4 and for the online doc), the css can be
reorganized later.

----------

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

From report at bugs.python.org  Wed Oct  7 16:16:38 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 07 Oct 2009 14:16:38 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1254924998.21.0.563421142795.issue7029@psf.upfronthosting.co.za>


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

Ok, thanks for the info.
We are currently using the modified version in house for monitoring our 
builds and that's ok for my purposes.  I have set the -C 0 and --timer 
systimes.processtime as default for us.
I'll close this now and leave you to do the rewrite.

----------
resolution:  -> later
status: open -> closed

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

From report at bugs.python.org  Wed Oct  7 16:39:33 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 07 Oct 2009 14:39:33 +0000
Subject: [issue6894] urllib2 doesn't respect "no_proxy" environment
	(python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1254926373.05.0.846581618526.issue6894@psf.upfronthosting.co.za>


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


----------
nosy: +Arfrever, orsenthil

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

From report at bugs.python.org  Wed Oct  7 16:44:50 2009
From: report at bugs.python.org (Koen van de Sande)
Date: Wed, 07 Oct 2009 14:44:50 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1254926690.06.0.848687766545.issue4120@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

Thanks Christoph, those are two important fixes to the patch. I'm +1 on 
having this in the next 2.6 maintenance release.

----------

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

From report at bugs.python.org  Wed Oct  7 17:31:17 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2009 15:31:17 +0000
Subject: [issue7075] Bug while put a set on a dict
In-Reply-To: <1254887171.46.0.861154287703.issue7075@psf.upfronthosting.co.za>
Message-ID: <1254929477.47.0.9575044943.issue7075@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid

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

From report at bugs.python.org  Wed Oct  7 17:55:12 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Oct 2009 15:55:12 +0000
Subject: [issue6894] urllib2 doesn't respect "no_proxy" environment
	(python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1254930912.85.0.631363272832.issue6894@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

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

From report at bugs.python.org  Wed Oct  7 18:15:50 2009
From: report at bugs.python.org (Chris Lambacher)
Date: Wed, 07 Oct 2009 16:15:50 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1254932150.44.0.929384586045.issue969718@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I am running into a problem related to this. I am attempting to cross
compile extensions but Fedora includes -march in the OPT variable. Since
there is no way to exclude the OPT values the build fails.

It seems that forcing OPT to stay the same is a disservice generally
speaking since as Marien said you potentially get extra conflicting
flags (-O seems like a stand-out since that could mess with gdb).

2.6 and 3.1 say:
        if 'CFLAGS' in os.environ:
            cflags = opt + ' ' + os.environ['CFLAGS']
            ldshared = ldshared + ' ' + os.environ['CFLAGS']

There is no ability to override opt. I'd be willing to put together a
patch to allow opt to be overridden by an environment variable if I
could get some support for this from a core maintainer.

I am also open to other suggestions about how to get around this. I
potentially have time to put into fixing this (or the more general cross
compile issue).

----------
nosy: +lambacck

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

From report at bugs.python.org  Wed Oct  7 18:23:57 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Oct 2009 16:23:57 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1254932637.4.0.793872342826.issue4120@psf.upfronthosting.co.za>


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

Just a note on the style of the msvc9compiler_stripruntimes_revised.diff
patch:

 * please try to use lines with at most 80 chars only

 * it would be better to use regexps to do the search&replace and
perhaps add wildcards to catch future SP-versions of VC9 as well

Added Distuils as component, since the patch is targeting distutils and
extensions, not the Python build process.

----------
components: +Distutils
nosy: +lemburg

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

From report at bugs.python.org  Wed Oct  7 19:04:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Oct 2009 17:04:41 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254935081.93.0.00769669827497.issue7048@psf.upfronthosting.co.za>


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

Mike's response makes sense to me.  If the precision is 2, the result
should round to that precision.  The documents showing the theory behind
the decimal spec indicate that in general mathematical operations are
exact, only the results get rounded.   Also IIRC, the use of
InvalidOperation is limited to the mathematical part, not the rounding step.

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

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

From report at bugs.python.org  Wed Oct  7 19:46:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 17:46:59 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254937619.48.0.0987502858903.issue7048@psf.upfronthosting.co.za>


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

Patch to update to the most recent official set of tests.

With this patch, logb and scaleb fail.

----------
keywords: +patch
Added file: http://bugs.python.org/file15070/decimal_testcases.patch

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

From report at bugs.python.org  Wed Oct  7 19:49:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 17:49:16 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254937756.48.0.741421857129.issue7048@psf.upfronthosting.co.za>


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

Patch to fix logb.

----------
Added file: http://bugs.python.org/file15071/logb.patch

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

From report at bugs.python.org  Wed Oct  7 19:56:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 17:56:12 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254938172.07.0.977858198805.issue7048@psf.upfronthosting.co.za>


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

I don't understand the new scaleb testcases (from Mike).  They look like 
this:

precision:   34
maxExponent: 999999999
minExponent: -999999999
-- integer overflow in 3.61 or earlier
scbx164 scaleb  1E-999999999  -1200000000  -> NaN Invalid_operation
-- out of range
scbx165 scaleb  -1E-999999999  +1200000000  -> NaN Invalid_operation

The specification says that the second operand should be in the range 
+/-2*(Emax+precision) inclusive, which in this case it is.  So clearly 
there are additional situations in which Invalid_operation should be 
signalled.  It's not clear to me what those conditions are.

----------

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

From report at bugs.python.org  Wed Oct  7 20:02:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 18:02:30 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254938550.55.0.224858945135.issue7048@psf.upfronthosting.co.za>


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

The IEEE 754-2008 description of scaleB makes a lot more sense, IMO:
scaleB(x, N) is simply x*10**N (assuming that B=10 and N is integral), 
rounded in the usual way.

The restriction in the specification seems arbitrary and questionable.  
Presumably it's intended to aid implementation in low-level languages.

----------

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

From report at bugs.python.org  Wed Oct  7 20:08:42 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 07 Oct 2009 18:08:42 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1254938922.78.0.708894851605.issue5949@psf.upfronthosting.co.za>


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

Sorry, 2.6.4 will be solely to remove the brown paper bag of 2.6.3 from
our heads.  This can go in 2.6.5 though.

----------

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

From report at bugs.python.org  Wed Oct  7 20:10:27 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Oct 2009 18:10:27 +0000
Subject: [issue7078] struct help in the interpreter does not explain about the
	fmt option
In-Reply-To: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
Message-ID: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>


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

>>> help(struct) mentions the functions which use fmt characters.
The builtin help does not mention the fmt characters and their meaning.
One should go online if he has to refer them.

----------
keywords: easy
messages: 93709
nosy: orsenthil
priority: low
severity: normal
status: open
title: struct help in the interpreter does not explain about the fmt option
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Oct  7 20:10:57 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Oct 2009 18:10:57 +0000
Subject: [issue7078] struct help in the interpreter does not explain about the
	fmt option
In-Reply-To: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
Message-ID: <1254939057.25.0.720719704383.issue7078@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl

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

From report at bugs.python.org  Wed Oct  7 20:23:12 2009
From: report at bugs.python.org (Forest Bond)
Date: Wed, 07 Oct 2009 18:23:12 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1254939792.92.0.587250709318.issue1488934@psf.upfronthosting.co.za>


Changes by Forest Bond <forest at alittletooquiet.net>:


----------
nosy: +forest_atq
versions: +Python 2.6

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

From report at bugs.python.org  Wed Oct  7 20:52:03 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Oct 2009 18:52:03 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254941523.99.0.413350235415.issue7049@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This whole thing is indeed a matter of taste, so I'd close the bug if no
one else is interested.

----------

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

From report at bugs.python.org  Wed Oct  7 20:56:52 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Oct 2009 18:56:52 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254941812.56.0.484334591255.issue7049@psf.upfronthosting.co.za>


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

I would like to look at this for a bit before it gets closed.

----------
assignee: mark.dickinson -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Wed Oct  7 20:59:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 18:59:19 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254941959.19.0.327196778787.issue7049@psf.upfronthosting.co.za>


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

Raymond, can I recommend deprecating and eventually removing three-
argument pow support from Decimal?

----------

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

From report at bugs.python.org  Wed Oct  7 21:04:37 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 07 Oct 2009 19:04:37 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1254942277.45.0.0640902322135.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The attached patch uses a regular expression.

----------
Added file: http://bugs.python.org/file15072/msvc9compiler_stripruntimes_regexp.diff

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

From report at bugs.python.org  Wed Oct  7 21:09:48 2009
From: report at bugs.python.org (brimac)
Date: Wed, 07 Oct 2009 19:09:48 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1254924097.23.0.899216769117.issue6670@psf.upfronthosting.co.za>
Message-ID: <9bd6f93d0910071209m7e80c9fpf3504fc06a565283@mail.gmail.com>


brimac <brimac at bcs.org> added the comment:

Hi Ezio

Thanks again.

Brimac

2009/10/7 Ezio Melotti <report at bugs.python.org>

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> > I'm not sure what happens now. Will somebody fix it?
>
> Now that the problem and the solution are known, Georg will probably fix
> it at some point. The "!important" could be used as a temporary
> workaround (e.g. for 2.6.4 and for the online doc), the css can be
> reorganized later.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6670>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________
-------------- next part --------------
Hi Ezio<br><br>Thanks again.<br><br>Brimac<br><br><br><div class="gmail_quote">2009/10/7 Ezio Melotti <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
Ezio Melotti &lt;<a href="mailto:ezio.melotti at gmail.com">ezio.melotti at gmail.com</a>&gt; added the comment:<br>
<br>
</div><div class="im">&gt; I&#39;m not sure what happens now. Will somebody fix it?<br>
<br>
</div>Now that the problem and the solution are known, Georg will probably fix<br>
it at some point. The &quot;!important&quot; could be used as a temporary<br>
workaround (e.g. for 2.6.4 and for the online doc), the css can be<br>
reorganized later.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6670" target="_blank">http://bugs.python.org/issue6670</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Wed Oct  7 21:26:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 19:26:24 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254943584.82.0.583840469671.issue7048@psf.upfronthosting.co.za>


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

Applied the fix for logb in r75275 (trunk), r75276 (py3k) and r75277 
(release31-maint).  r75275 still needs to be merged to the release26-maint 
branch once it's unfrozen.

----------

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

From report at bugs.python.org  Wed Oct  7 21:42:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2009 19:42:57 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1254944577.77.0.501579926437.issue7077@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Wed Oct  7 22:09:37 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Oct 2009 20:09:37 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1254942277.45.0.0640902322135.issue4120@psf.upfronthosting.co.za>
Message-ID: <4ACCF57C.6090104@egenix.com>


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

Christoph Gohlke wrote:
> 
> Christoph Gohlke <cgohlke at uci.edu> added the comment:
> 
> The attached patch uses a regular expression.

Much better, thanks.

----------
title: Do not embed manifest files in *.pyd when compiling with MSVC -> Do not embed manifest files in *.pyd when compiling with	MSVC

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

From report at bugs.python.org  Wed Oct  7 22:11:01 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Oct 2009 20:11:01 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254946261.65.0.92703388302.issue7049@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Deprecate on the grounds that it is slow in decimal.py or the
InvalidOperation issue?

I think pure integer arithmetic with the decimal type always requires
attention from the user, since in many functions one has to check for
Rounded/Inexact in order to get meaningful results. Here one has to
check for InvalidOperation, so I don't think it's a big deal. (This is
also the reason that I don't find the inconsistencies that you listed
particularly bothersome.)

If slowness is the reason: If any C module makes it into Python, this
would not be an issue any longer.

----------

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

From report at bugs.python.org  Wed Oct  7 22:13:50 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Oct 2009 20:13:50 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1254946430.98.0.680442858146.issue7048@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

precision:   34
maxExponent: 999999999
minExponent: -999999999
-- integer overflow in 3.61 or earlier
scbx164 scaleb  1E-999999999  -1200000000  -> NaN Invalid_operation
-- out of range
scbx165 scaleb  -1E-999999999  +1200000000  -> NaN Invalid_operation

I would say that this is implementation specific, as a workaround for
the overflow. This isn't in the spec at the moment.

----------

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

From report at bugs.python.org  Wed Oct  7 22:16:53 2009
From: report at bugs.python.org (thewtex)
Date: Wed, 07 Oct 2009 20:16:53 +0000
Subject: [issue6962] traceback.format_exception_only does not return
	SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1254946613.11.0.18963259772.issue6962@psf.upfronthosting.co.za>


thewtex <matt at mmmccormick.com> added the comment:

Sorry about the lack of the attached file.  I will try again and include
it inline.  

That other patch does not fix the bug I am seeing, which is experienced
while using traceback.format_exception_only directly.

Thanks.

--- /usr/lib/python2.6/traceback.py     2009-09-23 19:49:17.000000000 -0500
+++ /home/matt/tmp/traceback.py 2009-09-21 17:09:49.590440613 -0500
@@ -190,11 +190,10 @@
         if badline is not None:
             lines.append('    %s\n' % badline.strip())
             if offset is not None:
-                caretspace = badline[:offset].lstrip()
+                caretspace = badline[:offset-1].lstrip()
                 # non-space whitespace (likes tabs) must be kept for
alignment
                 caretspace = ((c.isspace() and c or ' ') for c in
caretspace)
-                # only three spaces to account for offset1 == pos 0
-                lines.append('   %s^\n' % ''.join(caretspace))
+                lines.append('    %s^\n' % ''.join(caretspace))
             value = msg
 
     lines.append(_format_final_exc_line(stype, value))

----------
keywords: +patch
status: closed -> open
Added file: http://bugs.python.org/file15074/traceback.patch

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

From report at bugs.python.org  Wed Oct  7 22:17:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2009 20:17:43 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254946663.3.0.877032715239.issue7049@psf.upfronthosting.co.za>


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

I was suggesting that it be deprecated on the grounds that:

(1) It's not part of the Decimal standard.
(2) It's not implemented for Python (binary) floats, so why implement
    it for decimal floats?
(3) It's severely use-case challenged.

It's a pure integer-based number-theoretic function that has no place in 
the Decimal module.

----------

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

From report at bugs.python.org  Wed Oct  7 22:36:52 2009
From: report at bugs.python.org (David Bonner)
Date: Wed, 07 Oct 2009 20:36:52 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1254947812.77.0.750669475815.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

I can remove the boilerplate from the code as long as I add the
following to the submittal:

VMware, Inc. is providing this bz2 module patch to you under the terms
of the Apache License 2.0 with the understanding that you plan to
re-license this under the terms and conditions of the Python License.
This patch is provided as is, with no warranties or support. VMware
disclaims all liability in connection with the use/inability to use this
patch. Any use of the attached is considered acceptance of the above.

----------
Added file: http://bugs.python.org/file15075/py3k_bz2.patch

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

From report at bugs.python.org  Wed Oct  7 23:07:48 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Oct 2009 21:07:48 +0000
Subject: [issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1254949668.53.0.518315715448.issue7049@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

(1) is clearly true. I wonder about (2) and (3):

The decimal data type is specified to be usable for integer arithmetic.
With a high precision (and traps for Rounded/Inexact) I think it's
reasonably convenient to use.

----------

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

From report at bugs.python.org  Wed Oct  7 23:10:45 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Oct 2009 21:10:45 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>


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

I noticed that file_close() calls close_the_file(), then frees the
buffer for the file object.  However, close_the_file() may fail and
return NULL if the file object is currently in use by another thread, in
which case freeing the buffer from underneath the C stdio library may
cause a crash.

Here's the relevant bit of code from fileobject.c:

static PyObject *
file_close(PyFileObject *f)
{
        PyObject *sts = close_the_file(f);
        PyMem_Free(f->f_setbuf);
        f->f_setbuf = NULL;
        return sts;
}

I think the two middle lines of the function should be wrapped in an "if
(sts)" block.

Attached is a short program that causes python to crash on two of my
systems (Windows XP running Python 2.6.3 and Debian running Python 2.5)
and a patch with my proposed fix.

I think Python 3 is immune because the I/O code has been completely
rewritten.  I have not checked the Python 3 code to see if there are any
analogous problems in the new code, however.

----------
components: IO, Interpreter Core
files: fileobject.diff
keywords: patch
messages: 93723
nosy: stutzbach
severity: normal
status: open
title: file_close() ignores return value of close_the_file
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15076/fileobject.diff

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

From report at bugs.python.org  Wed Oct  7 23:11:21 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Oct 2009 21:11:21 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1254949881.02.0.0471088034499.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Added file: http://bugs.python.org/file15077/crash.py

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

From report at bugs.python.org  Wed Oct  7 23:15:20 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 07 Oct 2009 21:15:20 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1254950120.33.0.323696506892.issue7077@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

To do this in a non-arbitrary way, it would make sense for the
SysLogHandler (and perhaps the other socket-based handlers, too) to grow
an optional encoding argument to their constructors, to be used to
encode when converting from unicode to str (str -> bytes for Py3K).

How does that sound?

----------

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

From report at bugs.python.org  Wed Oct  7 23:26:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2009 21:26:23 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1254950783.34.0.769956556718.issue3563@psf.upfronthosting.co.za>


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

Thanks very much for the patch; Committed in r75278.

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

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

From report at bugs.python.org  Wed Oct  7 23:46:52 2009
From: report at bugs.python.org (Shawn Ligocki)
Date: Wed, 07 Oct 2009 21:46:52 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1254952012.41.0.803313516915.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

A major pro for pseudo-random number generators is that they are
deterministic, that is, you can save a load the state, start from the
same seed and reproduce results, etc. At least in science (and probably
other areas) this reproducibility can be vital in a random class.

It really depends on your application though. In my use, I was
originally using normal random to produce seeds for another programs
random number generator. This ended up producing many identical results
and thus not producing an appropriate random sampling. Rather than
trying to figure out a proper way to do this with a PRNG I decided to
just use a completely random source, urandom was close enough for my needs.

I believe that is its strongest value, not having the strange artifacts
that PRNGs have. But I'm not completely sure how true that claim is :)

----------

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

From report at bugs.python.org  Thu Oct  8 00:13:33 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 07 Oct 2009 22:13:33 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1254953613.56.0.106706061648.issue7071@psf.upfronthosting.co.za>


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

So there are two issues here - the terrible error message when an
install fails with an access denied error and the fact that distutils
attempts to compile bytecode under IronPython.

----------

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

From report at bugs.python.org  Thu Oct  8 01:01:43 2009
From: report at bugs.python.org (egreen)
Date: Wed, 07 Oct 2009 23:01:43 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>


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

The strxfrm function in the locale module can potentially raise a
MemoryError.

The failing malloc is in Modules/_localemodule.c, line 291.

This is because the variable n0 of type Py_ssize_t is passed to
PyArg_ParseTuple, which expects an int when PY_SSIZE_T_CLEAN is not defined.

Patch attached, which also fixes an unrelated memory leak.

----------
components: Library (Lib)
files: strxfrm_MemoryError.patch
keywords: patch
messages: 93728
nosy: egreen, loewis
severity: normal
status: open
title: locale.strxfrm raises MemoryError
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15078/strxfrm_MemoryError.patch

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

From report at bugs.python.org  Thu Oct  8 01:04:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Oct 2009 23:04:33 +0000
Subject: [issue6962] traceback.format_exception_only does not return
	SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1254956673.64.0.0143942584438.issue6962@psf.upfronthosting.co.za>


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

OK, but your patch certainly interferes with issue1326077.
If format_exception_only changes, print_exception will display things 
differently.  And the precise output is now part of the test suite (in 
test_traceback.py)

----------
resolution: duplicate -> 

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

From report at bugs.python.org  Thu Oct  8 01:58:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2009 23:58:45 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254959925.77.0.0294969560886.issue7058@psf.upfronthosting.co.za>


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

Committed to trunk in r75255, py3k in r75279, and 3.1 in r75280. 
Leaving open until 2.6 is unfrozen and I can commit it there as well.

----------
assignee:  -> r.david.murray
resolution:  -> accepted
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Thu Oct  8 02:00:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2009 00:00:20 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254960020.64.0.743195730147.issue7058@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15044/regrtest_guards.patch

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

From report at bugs.python.org  Thu Oct  8 02:07:06 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Oct 2009 00:07:06 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1254960426.13.0.182786952454.issue5915@psf.upfronthosting.co.za>


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

It would be useful to have the surrogateescape error handler backported
to 2.7 to make it easier to start handling the kind of data it is needed
for.

----------
nosy: +exarkun

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

From report at bugs.python.org  Thu Oct  8 03:11:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Oct 2009 01:11:11 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1254964271.83.0.336261497273.issue7058@psf.upfronthosting.co.za>


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

The cwd should also be checked/restored to avoid problems like #7066.

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

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

From report at bugs.python.org  Thu Oct  8 03:38:32 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Oct 2009 01:38:32 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1254965912.04.0.69546176521.issue7079@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Oct  8 04:26:20 2009
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 08 Oct 2009 02:26:20 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1254968780.1.0.0340603825924.issue7071@psf.upfronthosting.co.za>


Changes by Dino Viehland <dinov at microsoft.com>:


----------
nosy: +DinoV

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

From report at bugs.python.org  Thu Oct  8 05:38:15 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 08 Oct 2009 03:38:15 +0000
Subject: [issue7078] struct help in the interpreter does not explain about the
	fmt option
In-Reply-To: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
Message-ID: <1254973095.21.0.263207344092.issue7078@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The module docstring (for _struct) already existed, but was not exposed 
as struct.__doc__
This patch fixes the problem; also, there was a missing format 
character ("?")

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file15079/struct.diff

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

From report at bugs.python.org  Thu Oct  8 08:26:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Oct 2009 06:26:13 +0000
Subject: [issue6962] traceback.format_exception_only does not return
	SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1254983173.78.0.424766028392.issue6962@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
resolution:  -> duplicate

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

From report at bugs.python.org  Thu Oct  8 09:12:16 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 08 Oct 2009 07:12:16 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1254985936.98.0.96212060798.issue7079@psf.upfronthosting.co.za>


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


----------
assignee:  -> gregory.p.smith
priority:  -> high

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

From report at bugs.python.org  Thu Oct  8 10:09:17 2009
From: report at bugs.python.org (Robert Szefler)
Date: Thu, 08 Oct 2009 08:09:17 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1254989357.9.0.704232203528.issue7077@psf.upfronthosting.co.za>


Robert Szefler <robert.szefler at redefine.pl> added the comment:

Fine with me, though problems would arise. Default encoding for example.
If encoding selection is mandatory it would break compatibility. Using
default locale is not such a good idea - local machine's locale would
generally not need to have any correlation to the remote logger's.

Maybe the best solution would be to coerce the text to ASCII per default
(such as not to break current semantics) but fix the exception thrown
(throw an Unicode*Error) and allow an optional encoding parameter to
handle non-ASCII characters?

----------

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

From report at bugs.python.org  Thu Oct  8 10:41:10 2009
From: report at bugs.python.org (Michael Wise)
Date: Thu, 08 Oct 2009 08:41:10 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1254991270.73.0.752102960789.issue4064@psf.upfronthosting.co.za>


Michael Wise <Michael.Wise at uwa.edu.au> added the comment:

While the discussion seems to think the matter is closed, I wanted to
install numpy 1.30 which requires Python 2.6 and all my machines are PPC
(G4 or G5 - nice architectures). 

gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ...

followed, unsurprisingly, by:
gcc-4.0: installation problem, cannot exec
'i686-apple-darwin8-gcc-4.0.0': No such file or directory

Work around, please?

Cheers
MichaelW

----------
nosy: +mw263

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

From report at bugs.python.org  Thu Oct  8 10:48:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Oct 2009 08:48:34 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1254991714.95.0.494644083692.issue5511@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords:  -needs review, patch

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

From report at bugs.python.org  Thu Oct  8 10:56:14 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 08 Oct 2009 08:56:14 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1254992174.81.0.402880358162.issue4064@psf.upfronthosting.co.za>


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

Michael: please file a new issue for this, your problem seems to be 
unrelated to this one.

In that issue include information about:

1) The python version you are using
2) The version of MacOSX
3) The version of Xcode (open /Developer/Applications/Xcode.app,
    check the version in the About dialog)

----------

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

From report at bugs.python.org  Thu Oct  8 11:03:33 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 08 Oct 2009 09:03:33 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254989357.9.0.704232203528.issue7077@psf.upfronthosting.co.za>
Message-ID: <747090.49681.qm@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Robert Szefler  added the comment:

> 
> Fine with me, though problems would arise. Default encoding for example.
> If encoding selection is mandatory it would break compatibility. Using
> default locale is not such a good idea - local machine's locale would
> generally not need to have any correlation to the remote logger's.

I'm not planning to make encoding selection mandatory: I would provide a parameter encoding=None so backward compatibility is preserved.

On 2.x: During output, a check will be made for Unicode. If not found, the data is output as is. Otherwise (if Unicode) it's encoded using either the specified encoding (if not None) or some default - for example, locale.getpreferredencoding().

I understand what you're saying about the locales of two different machines not being the same - but there's no way around this, because if a socket receives bytes representing text, it needs to know what encoding was used so that it can reconstruct the Unicode correctly. So that information at least needs to be known at the receiving end, rather than guessd. While 'utf-8' might be a reasonable choice, I'm not sure it should be enforced. So the code sending the bytes can specify e.g. 'cp1251' and the other end has to know so it can decode correctly. I've posted on python-dev for advice about what encoding to use if none is specified.

On 3.x: We will always be passing Unicode in so we will always need to convert to bytes using some encoding. Again, if not specified, a suitable default encoding needs to be chosen.

> Maybe the best solution would be to coerce the text to ASCII per default
> (such as not to break current semantics) but fix the exception thrown
> (throw an Unicode*Error) and allow an optional encoding parameter to
> handle non-ASCII characters?

I'm not exactly sure what you mean, but I think I've covered it in my comments above. To summarise:

On 2.x, encoding is not mandatory but if Unicode is passed in, either a specified encoding or a suitable default encoding will be used to encode the Unicode into str.

On 3.x, encoding is not mandatory and Unicode should always be passed in, which will be encoded to bytes using either a specified encoding or a suitable default encoding.

----------

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

From report at bugs.python.org  Thu Oct  8 13:18:17 2009
From: report at bugs.python.org (Anh Hai Trinh)
Date: Thu, 08 Oct 2009 11:18:17 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1255000697.34.0.913034156379.issue6280@psf.upfronthosting.co.za>


Changes by Anh Hai Trinh <anh.hai.trinh at gmail.com>:


----------
nosy: +aht
versions: +Python 2.6

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

From report at bugs.python.org  Thu Oct  8 13:37:48 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Oct 2009 11:37:48 +0000
Subject: [issue7081] ">" formatting behaving like "=" formatting
In-Reply-To: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>
Message-ID: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>


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

The ">" alignment flag to format() is not right aligning numbers
properly on trunk and the py3k branch:

>>> format(0x1234, "+#08x")
'+0x01234'
>>> format(0x1234, "0=+#8x")
'+0x01234'
>>> format(0x1234, "0>+#8x")
'+0x01234'

That last one should be:
>>> format(0x1234, "0>+#8x")
'0+0x1234'

The intended behaviour of ">" is more obviously correct when you
consider a leading space instead of a leading zero:

>>> format(0x1234, " >+#8x")
' +0x1234'

This is only an error on the development versions - the behaviour is
correct on the 2.6 and 3.1 maintenance branches.

----------
assignee: eric.smith
messages: 93738
nosy: eric.smith, ncoghlan
priority: normal
severity: normal
status: open
title: ">" formatting behaving like "=" formatting
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Oct  8 13:48:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 11:48:45 +0000
Subject: [issue7081] ">" formatting behaving like "=" formatting
In-Reply-To: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>
Message-ID: <1255002525.17.0.369568695692.issue7081@psf.upfronthosting.co.za>


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

Is this the same problem as in issue 6902?

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Oct  8 14:11:28 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 08 Oct 2009 12:11:28 +0000
Subject: [issue7081] ">" formatting behaving like "=" formatting
In-Reply-To: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>
Message-ID: <1255003888.37.0.516161957551.issue7081@psf.upfronthosting.co.za>


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

I think they're the same issue, relating to what happens if there's an
alignment specifier supplied along with '0'. I'm planning on working on
this issue this weekend and I'll verify if it's the same problem.

----------

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

From report at bugs.python.org  Thu Oct  8 14:26:41 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Oct 2009 12:26:41 +0000
Subject: [issue7081] ">" formatting behaving like "=" formatting
In-Reply-To: <1255001868.04.0.9715466253.issue7081@psf.upfronthosting.co.za>
Message-ID: <1255004801.79.0.182260999781.issue7081@psf.upfronthosting.co.za>


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

Just checked, and yep, it's a duplicate of 6902 - the problem does
indeed go away if I use a different formatting character.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Built-in types format incorrectly with 0 padding.

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

From report at bugs.python.org  Thu Oct  8 14:31:09 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Oct 2009 12:31:09 +0000
Subject: [issue6902] Built-in types format incorrectly with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1255005069.43.0.779017239159.issue6902@psf.upfronthosting.co.za>


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

Note that the 2.6 branch didn't seem to suffer this problem when I
checked it earlier tonight.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Oct  8 14:38:33 2009
From: report at bugs.python.org (Darren Worrall)
Date: Thu, 08 Oct 2009 12:38:33 +0000
Subject: [issue7082] Patch for get attachments in email
Message-ID: <1255005513.55.0.498801642336.issue7082@psf.upfronthosting.co.za>


Changes by Darren Worrall <dw at darrenworrall.co.uk>:


----------
nosy: DazWorrall
severity: normal
status: open
title: Patch for get attachments in email
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  8 14:43:53 2009
From: report at bugs.python.org (Darren Worrall)
Date: Thu, 08 Oct 2009 12:43:53 +0000
Subject: [issue7082] Patch for get attachments in email
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>


New submission from Darren Worrall <dw at darrenworrall.co.uk>:

Finger spasm submitted this without a comment, apologies.

I believe the fix applied in http://bugs.python.org/issue1403349 is not
actually correct. In the case where Content-Disposition is missing, the
'name' parameter should be on Content-Type - but the original patch
looks for 'name' on Content-Disposition, which doesn't exist.

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

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

From report at bugs.python.org  Thu Oct  8 14:50:41 2009
From: report at bugs.python.org (Darren Worrall)
Date: Thu, 08 Oct 2009 12:50:41 +0000
Subject: [issue7082] Patch for get attachments in email
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255006241.72.0.35277077209.issue7082@psf.upfronthosting.co.za>


Darren Worrall <dw at darrenworrall.co.uk> added the comment:

Patch is against 2.7 trunk, but should backport without any resistance.

----------
keywords: +patch
Added file: http://bugs.python.org/file15080/message-getfilename.patch

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

From report at bugs.python.org  Thu Oct  8 14:54:17 2009
From: report at bugs.python.org (Darren Worrall)
Date: Thu, 08 Oct 2009 12:54:17 +0000
Subject: [issue7082] Patch for get attachments in email
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255006457.38.0.616354375148.issue7082@psf.upfronthosting.co.za>


Changes by Darren Worrall <dw at darrenworrall.co.uk>:


----------
nosy: +barry
versions: +Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Thu Oct  8 15:49:58 2009
From: report at bugs.python.org (=?utf-8?b?QW5kcsOpIEJqw6RyYnk=?=)
Date: Thu, 08 Oct 2009 13:49:58 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>


New submission from Andr? Bj?rby <andre.bjarby at gmail.com>:

Running the attached script shows that locals() behaves differently
depending on whether sys.settrace() is active.

This does not occur when calling locals() in the global scope, only when
used inside functions.

----------
components: Extension Modules, Interpreter Core
files: localstest.py
messages: 93745
nosy: andbj
severity: normal
status: open
title: locals() behaviour differs when tracing is in effect
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15081/localstest.py

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

From report at bugs.python.org  Thu Oct  8 15:55:55 2009
From: report at bugs.python.org (Darren Worrall)
Date: Thu, 08 Oct 2009 13:55:55 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255010155.77.0.579729362762.issue7082@psf.upfronthosting.co.za>


Changes by Darren Worrall <dw at darrenworrall.co.uk>:


----------
title: Patch for get attachments in email -> Patch for get_filename in email.message when content-disposition is missing

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

From report at bugs.python.org  Thu Oct  8 16:29:26 2009
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 08 Oct 2009 14:29:26 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1255012166.72.0.219086241518.issue5511@psf.upfronthosting.co.za>


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

Added two tests -- test_close and test_close_on_exception, which check
if fp is None after __exit__ from a normal and exception case.

----------
keywords: +patch
Added file: http://bugs.python.org/file15082/issue5511_complete_20091008.patch

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

From report at bugs.python.org  Thu Oct  8 16:52:17 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Oct 2009 14:52:17 +0000
Subject: [issue6962] traceback.format_exception_only does not return
	SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1255013537.45.0.555667798608.issue6962@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution: duplicate -> 

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

From report at bugs.python.org  Thu Oct  8 17:37:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2009 15:37:21 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255016241.2.0.789061159118.issue7083@psf.upfronthosting.co.za>


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

The same is thing is true of the frame's f_locals attribute. This
attribute is a copy of the local variables in the frame, because the
internal storage of these variables is a raw C array for faster access.
This copy is only synchronized back when a tracing function returns, so
as to allow implementing a debugger.

>>> def f():
...   a = 1
...   l = sys._getframe().f_locals
...   b = 2
...   return l
... 
>>> f()
{'a': 1}

The above optimization (raw C array for faster access of local
variables) is not done at the global scope, and therefore locals() at
that scope give you direct access to the variables' internal store
(which is, actually, the module's __dict__).

>>> import __main__
>>> __main__.__dict__ is locals()
True

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

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

From report at bugs.python.org  Thu Oct  8 18:04:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 16:04:12 +0000
Subject: [issue7078] struct help in the interpreter does not explain about the
	fmt option
In-Reply-To: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
Message-ID: <1255017852.7.0.951519932964.issue7078@psf.upfronthosting.co.za>


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

Thanks for the patch, Gabriel!

Applied to trunk in r75283.  (I also fixed the indentation for the
list of order/size/alignment specifiers.)  Merged to py3k in r75284, 
release31-maint in r75285.  Leaving open for the merge to release26-maint.

----------
assignee: georg.brandl -> mark.dickinson
components: +Extension Modules
nosy: +mark.dickinson
resolution:  -> fixed
versions:  -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  8 18:25:37 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Thu, 08 Oct 2009 16:25:37 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1255019137.6.0.961693514234.issue6845@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


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

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

From report at bugs.python.org  Thu Oct  8 18:34:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 16:34:49 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1255019689.45.0.264702421404.issue7048@psf.upfronthosting.co.za>


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

I've updated to the newest version of the test-suite in r75285 through 
r75287.  As before, r75285 needs to be backported to the 2.6 maintenance 
branch once its unfrozen.

I'm currently skipping those two scaleb tests, until we work out what 
should be going on here.

----------

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

From report at bugs.python.org  Thu Oct  8 18:52:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2009 16:52:03 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1255020723.27.0.515605081403.issue6845@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Oct  8 18:52:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2009 16:52:18 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1255020739.0.0.763320252354.issue6845@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -None
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2

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

From report at bugs.python.org  Thu Oct  8 18:58:26 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 08 Oct 2009 16:58:26 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255021106.43.0.609008659887.issue7083@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

So there's no bug here right? It's even documented.

----------
nosy: +gvanrossum
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Oct  8 19:35:52 2009
From: report at bugs.python.org (=?utf-8?b?QW5kcsOpIEJqw6RyYnk=?=)
Date: Thu, 08 Oct 2009 17:35:52 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255023352.22.0.955718805986.issue7083@psf.upfronthosting.co.za>


Andr? Bj?rby <andre.bjarby at gmail.com> added the comment:

It's documented that "The contents of this dictionary should not be
modified; changes may not affect the values of local variables used by
the interpreter."

The script does the opposite. Perhaps an addition to the documentation?
"The contents of this dictionary may not be affected by local variables
used by the interpreter".

----------

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

From report at bugs.python.org  Thu Oct  8 19:37:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 17:37:35 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255023455.78.0.315916845053.issue7051@psf.upfronthosting.co.za>


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

Benjamin, which docs are you looking at here?  The ones at:

http://docs.python.org/library/stdtypes.html#string-formatting-operations

say:

"""Floating point format. Uses lowercase exponential format if exponent is 
less than -4 or not less than precision, decimal format otherwise."""

which seem quite specific to me (though it could be made clearly exactly 
*what* exponent is meant here).

----------

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

From report at bugs.python.org  Thu Oct  8 19:37:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2009 17:37:52 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255023472.45.0.529491053604.issue7083@psf.upfronthosting.co.za>


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


----------
assignee:  -> georg.brandl
components: +Documentation -Extension Modules, Interpreter Core
nosy: +georg.brandl
versions: +Python 2.7, Python 3.2 -Python 2.4, Python 2.5

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

From report at bugs.python.org  Thu Oct  8 19:39:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 17:39:08 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255023548.77.0.64281854671.issue7051@psf.upfronthosting.co.za>


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

Ah.  Found them.

http://docs.python.org/library/string.html#formatspec

----------

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

From report at bugs.python.org  Thu Oct  8 20:06:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 18:06:42 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255025202.95.0.774373454914.issue7051@psf.upfronthosting.co.za>


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

Proposed revision:

General format.  For a given precision ``p >= 1``, this rounds the number to ``p`` 
significant digits and then formats the result in either fixed-point format or in 
scientific notation, depending on its magnitude.  The precise rules are as follows: 
suppose that the result formatted with presentation type ``e`` and precision ``p-1`` 
would have exponent ``exp``.  Then if ``-4 <= exp < p``, the number is formatted as 
if with presentation type ``f`` and precision chosen in such a way as to give ``p`` 
significant digits.  Otherwise, the number is formatted as if with presentation type 
``e`` and precision ``p-1``.

A precision of ``0`` is treated as equivalent to a precision of ``1``.

----------

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

From report at bugs.python.org  Thu Oct  8 20:20:19 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 08 Oct 2009 18:20:19 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255026019.31.0.0865448160027.issue7051@psf.upfronthosting.co.za>


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

That wording is okay with me. Maybe run it by Georg to see if he has any
suggestions? Or just check it in and see if anyone complains.

But I'm okay with it as-is.

Thanks for doing this.
Eric.

----------

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

From report at bugs.python.org  Thu Oct  8 20:24:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 18:24:37 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255026277.11.0.461480587341.issue7051@psf.upfronthosting.co.za>


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

Thanks, Eric.  I noticed that the description was missing details of
what happens to trailing zeros (i.e., they're removed) and what happens
to special values:  infinities, zeros, nans.  Here's the revised revised 
text:

General format.  For a given precision ``p >= 1``, this rounds the
number to ``p`` significant digits and then formats the result in
either fixed-point format or in scientific notation, depending on its
magnitude.  The precise rules are as follows: suppose that the result
formatted with presentation type ``e`` and precision ``p-1`` would
have exponent ``exp``.  Then if ``-4 <= exp < p``, the number is
formatted as if with presentation type ``f`` and precision
``p-1-exp``.  Otherwise, the number is formatted as if with
presentation type ``e`` and precision ``p-1``.  In both cases trailing
zeros are removed from the significand, as is the decimal point if
there are no remaining digits following it.

Postive and negative infinity, positive and negative zero, and nans,
are formatted as ``inf``, ``-inf``, ``0``, ``-0`` and ``nan``
respectively.

A precision of ``0`` is treated as equivalent to a precision of ``1``.

----------

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

From report at bugs.python.org  Thu Oct  8 20:27:51 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 08 Oct 2009 18:27:51 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255026471.97.0.657508450969.issue7051@psf.upfronthosting.co.za>


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

I obviously hadn't thought of those cases, either. This version looks
good(er) to me.

----------

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

From report at bugs.python.org  Thu Oct  8 21:02:03 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 08 Oct 2009 19:02:03 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255028523.68.0.374583006782.issue7083@psf.upfronthosting.co.za>


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

I think the doc is clear enough if one reads and believes it.  The main
doc is "Update and return a dictionary representing the current local
symbol table." That pretty clearly says that subsequent changes to the
local symbol table may make the dict out of date until updated by a
subsequent call.

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

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

From report at bugs.python.org  Thu Oct  8 21:44:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2009 19:44:19 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255031059.11.0.616297591266.issue7082@psf.upfronthosting.co.za>


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

2.4 and 2.5 are open only for security patches, which this is not, so
I've removed them from versions, and added 3.1 and 3.2, which have the
same code.

The patch looks appropriate to me, and is what the original bug report
requested.

Note that the Content-Type name parameter has been deprecated for a long
time...see for example this thread:
http://www.imc.org/ietf-822/old-archive2/msg02121.html.  Support is
still required, however, since Microsoft's .NET framework, at least,
still supports setting the parameter (see
http://msdn.microsoft.com/en-us/library/system.net.mime.contenttype.name.aspx)

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.4, Python 2.5

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

From report at bugs.python.org  Thu Oct  8 21:45:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2009 19:45:52 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255031152.17.0.0567954149324.issue7082@psf.upfronthosting.co.za>


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


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Thu Oct  8 21:52:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 08 Oct 2009 19:52:11 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255031531.86.0.629661193309.issue7051@psf.upfronthosting.co.za>


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

The "as if with" feels strange, otherwise it is fine with me.

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

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

From report at bugs.python.org  Thu Oct  8 21:58:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 19:58:25 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255031905.43.0.749907056554.issue7051@psf.upfronthosting.co.za>


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

Okay.  I'll replace the 'as if with' with simply 'with'.  That doesn't 
quite meet my favoured level of pedantry any more, but it does read better 
and it's not going to lead to any confusion.  :)

----------

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

From report at bugs.python.org  Thu Oct  8 22:01:24 2009
From: report at bugs.python.org (=?utf-8?b?QW5kcsOpIEJqw6RyYnk=?=)
Date: Thu, 08 Oct 2009 20:01:24 +0000
Subject: [issue7083] locals() behaviour differs when tracing is in effect
In-Reply-To: <1255009798.45.0.553728595296.issue7083@psf.upfronthosting.co.za>
Message-ID: <1255032084.05.0.729002968305.issue7083@psf.upfronthosting.co.za>


Changes by Andr? Bj?rby <andre.bjarby at gmail.com>:


----------
components: +Extension Modules, Interpreter Core -Documentation
nosy:  -andbj
versions: +Python 2.4, Python 2.5 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Oct  8 22:03:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2009 20:03:46 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255032226.09.0.193358051415.issue7051@psf.upfronthosting.co.za>


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

I think the 'as if with' is probably valid English, but if you want to
make it sound better yet retain the same level of pedantry you could
instead say, e.g.: "in the same way as presentation type e using
precision p-1".

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  8 22:08:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 20:08:35 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255032515.6.0.23979264523.issue7051@psf.upfronthosting.co.za>


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

Thanks Georg and Eric for the feedback!  New wording committed in
r75289 (trunk), r75290 (py3k), r75291 (release31-maint).  Leaving open 
for the backport to release26-maint.

BTW, it's much easier to describe the rules in Python than in prose:

def strip_zero_dot(sig):
    return sig.rstrip('0').rstrip('.') if '.' in sig else sig

def gformat(x, p=6):
    if math.isinf(x) or math.isnan(x) or not x:
        return '{:.0f}'.format(x)
    p = max(p, 1)
    sig, exp = '{:.{}e}'.format(x, p-1).split('e')
    if -4 <= int(exp) < p:
        return strip_zero_dot('{:.{}f}'.format(x, p-1-int(exp)))
    else:
        return strip_zero_dot(sig) + 'e' + exp

----------
components: +Documentation
resolution:  -> fixed

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

From report at bugs.python.org  Thu Oct  8 22:08:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Oct 2009 20:08:57 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1255032537.65.0.0714995493892.issue7051@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Oct  8 23:35:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2009 21:35:08 +0000
Subject: [issue7084] printing a list releases the GIL carelessly
In-Reply-To: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>
Message-ID: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>


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

Function list_print() in listobject.c releases the GIL before calling
fprintf() but doesn't check the list size again when it gets the GIL
back. If another thread truncated the list, a crash can ensue. The
attached script crashes reliably here.

----------
files: list_print.py
messages: 93764
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: printing a list releases the GIL carelessly
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15083/list_print.py

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

From report at bugs.python.org  Fri Oct  9 00:45:31 2009
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 08 Oct 2009 22:45:31 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1255041931.4.0.742595893265.issue7071@psf.upfronthosting.co.za>


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


----------
nosy: +briancurtin

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

From report at bugs.python.org  Fri Oct  9 00:48:52 2009
From: report at bugs.python.org (Jiri Krivanek)
Date: Thu, 08 Oct 2009 22:48:52 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>


New submission from Jiri Krivanek <jiri.krivanek at betacontrol.cz>:

The following simple code works perfectly on W2K, WXP, Ubuntu, OSX10.4 
OSX10.5. It, however, stopped working on OSX10.6 (Snow Leopard): It 
simply crashes. It is a strptime() which causes problems to me.

Any idea? Any workaround?

import time
import thread

def test():
    print "TS: "
    print "%s" % str(time.strptime("2009-09-09 16-56-37", "%Y-%m-%d %H-
%M-%S"))
    
thread.start_new_thread (test, ())
time.sleep(2.0)

----------
assignee: ronaldoussoren
components: Macintosh
messages: 93765
nosy: kakacek, ronaldoussoren
severity: normal
status: open
title: strptime problem
type: crash
versions: Python 2.4

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

From report at bugs.python.org  Fri Oct  9 00:58:22 2009
From: report at bugs.python.org (Jr Aquino)
Date: Thu, 08 Oct 2009 22:58:22 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>


New submission from Jr Aquino <jr.aquino at citrixonline.com>:

This patch is to address the deficiency in sending syslog messages to an 
external syslog server via tcp or udp.

Currently the handler only really supports udp unless it is being 
redirected locally through a unix socket.

The submitted patch allows for the standard udp SOCK_DGRAM behavior to 
continue being the default, but allows for a protocol object to be defined 
as tcp to allow for the alternate protocol.

----------
components: Extension Modules
files: handlers.py.diff
keywords: patch
messages: 93766
nosy: enigma
severity: normal
status: open
title: logging.handlers.SysLogHandler with TCP support
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15084/handlers.py.diff

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

From report at bugs.python.org  Fri Oct  9 02:11:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2009 00:11:56 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255047116.22.0.0831727759926.issue7086@psf.upfronthosting.co.za>


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

I'll leave it to Vinay to pronounce on the request and the validity of
the patch, but a couple of comments on the mechanics of the patch:  You
have some rogue whitespace on one of the blank lines.  More importantly,
you are adding a keyword parameter at the beginning of the list of
keywords, which would change the semantics if someone passed in
arguments positionally.  Finally, you should check out PEP 8 about
Python style...the line length should be less the 80, which means your
docstring addition needs to be reformatted, as well as the __init__ line
itself.

Thanks for contributing!

Oh, and while I set the stage to test needed it doesn't look like there
are any existing tests for SysLogHandler....

----------
components: +Library (Lib) -Extension Modules
nosy: +r.david.murray, vinay.sajip
priority:  -> normal
stage:  -> test needed
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Oct  9 03:12:02 2009
From: report at bugs.python.org (Jr Aquino)
Date: Fri, 09 Oct 2009 01:12:02 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255050722.97.0.724786215134.issue7086@psf.upfronthosting.co.za>


Jr Aquino <jr.aquino at citrixonline.com> added the comment:

Here is the patch with the requested syntactical corrections.

----------
Added file: http://bugs.python.org/file15085/handlers.py.diff

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

From report at bugs.python.org  Fri Oct  9 03:13:52 2009
From: report at bugs.python.org (Jr Aquino)
Date: Fri, 09 Oct 2009 01:13:52 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255050832.84.0.262500322849.issue7086@psf.upfronthosting.co.za>


Changes by Jr Aquino <jr.aquino at citrixonline.com>:


Removed file: http://bugs.python.org/file15084/handlers.py.diff

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

From report at bugs.python.org  Fri Oct  9 03:22:03 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 09 Oct 2009 01:22:03 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1255051323.48.0.942319736333.issue7069@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I don't think we should test the actual type returned (bool); that 
would be overspecifying. The documentation doesn't promise it IS a 
boolean, and no other test for any isXXX() function checks the type 
either.
I'd remove the last five assertions.

----------

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

From report at bugs.python.org  Fri Oct  9 04:48:01 2009
From: report at bugs.python.org (s7v7nislands)
Date: Fri, 09 Oct 2009 02:48:01 +0000
Subject: [issue7087] use keyword 'as' in _xmlplus
In-Reply-To: <1255056480.98.0.446336342031.issue7087@psf.upfronthosting.co.za>
Message-ID: <1255056480.98.0.446336342031.issue7087@psf.upfronthosting.co.za>


New submission from s7v7nislands <s7v7nislands at gmail.com>:

In these files: _xmlplus/xpath/ParsedAbbreviatedAbsoluteLocationPath.py
_xmlplus/xpath/ParsedAbbreviatedRelativeLocationPath.py, use the keyword
'as'.

----------
messages: 93770
nosy: s7v7nislands
severity: normal
status: open
title: use keyword 'as' in _xmlplus
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  9 05:13:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Oct 2009 03:13:22 +0000
Subject: [issue7087] use keyword 'as' in _xmlplus
In-Reply-To: <1255056480.98.0.446336342031.issue7087@psf.upfronthosting.co.za>
Message-ID: <1255058002.06.0.954240204803.issue7087@psf.upfronthosting.co.za>


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

_xmlplus is not part of Python. Please report this bug to the PyXML
maintainers.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 05:17:19 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 09 Oct 2009 03:17:19 +0000
Subject: [issue7088] New (in 2.6) functions in signal module are not
	documented as unix-only
In-Reply-To: <1255058239.85.0.357925408849.issue7088@psf.upfronthosting.co.za>
Message-ID: <1255058239.85.0.357925408849.issue7088@psf.upfronthosting.co.za>


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

2.6 introduced several new functions to the signal module that are not
available on Windows (setitimer, getitimer, and siginterrupt).  However,
they aren't documented with Availability: Unix.

----------
assignee: georg.brandl
components: Documentation
messages: 93772
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: New (in 2.6) functions in signal module are not documented as unix-only
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct  9 05:57:09 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Oct 2009 03:57:09 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1255060629.71.0.424707065825.issue7085@psf.upfronthosting.co.za>


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

It fails for me as well on 10.6 (Intel) with 2.6 and trunk and did not 
fail on 10.5 (ppc). time.strptime does an import of a python module from C 
code so, not surprisingly, adding a time.strptime call in the main module 
prior to the thread.start_new_thread avoids the crash.

Attached is the stack trace of the crash with 2.6.4rc1.

----------
nosy: +ned.deily
versions: +Python 2.6, Python 2.7 -Python 2.4
Added file: http://bugs.python.org/file15086/Python_2009-10-08-204652_fimt-3.crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7085>
_______________________________________

From report at bugs.python.org  Fri Oct  9 06:58:15 2009
From: report at bugs.python.org (Jiri Krivanek)
Date: Fri, 09 Oct 2009 04:58:15 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1255064295.68.0.00168492259911.issue7085@psf.upfronthosting.co.za>


Jiri Krivanek <jiri.krivanek at betacontrol.cz> added the comment:

The suggested workaround helped to solve the issue to me. Thank for it 
very much.

I am using Python 2.4.4 and cannot upgrade to anything above 2.4 due to 
incompatibility between .pyc files (I have tenths of production sites with 
Python 2.4.4, with automatic update feature, onto which I only populate 
the .pyc files only, so upgrading to Python 2.5.x+ would cause all my 
sites to crash upon the next automatic update).

Consequently, from my perspective, this issue is solved and may be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7085>
_______________________________________

From report at bugs.python.org  Fri Oct  9 07:23:14 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2009 05:23:14 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1255065794.22.0.829529271353.issue7085@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It's confirmed on 2.5 - trunk, but it is not an issue in at least 3.1 and 
py3k.

As Ned pointed out, time imports _strptime.py from the standard library 
which is known to be a no-no. But still, it's odd that it crashed on Snow 
Leopard but not Leopard. I will leave this issue open for Ronald to make a 
call as to whether this is a Python issue or not as Python is dying in 
__CFInitialize().

----------
nosy: +brett.cannon
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7085>
_______________________________________

From report at bugs.python.org  Fri Oct  9 10:11:54 2009
From: report at bugs.python.org (Jan David Mol)
Date: Fri, 09 Oct 2009 08:11:54 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>


New submission from Jan David Mol <jjdmol at gmail.com>:

The shlex module does not function as expected in the presence of
comments when newlines are not whitespace. An example (attached):

>>> from shlex import shlex
>>> 
>>> lexer = shlex("a \n b")
>>> print ",".join(lexer)
a,b
>>> 
>>> lexer = shlex("a # comment \n b")
>>> print ",".join(lexer)
a,b
>>> 
>>> lexer = shlex("a \n b")
>>> lexer.whitespace=" "
>>> print ",".join(lexer)
a,
,b
>>> 
>>> lexer = shlex("a # comment \n b")
>>> lexer.whitespace=" "
>>> print ",".join(lexer)
a,b

Now where did my newline go? The comment ate it! Even though the docs
seem to indicate the newline is not part of the comment itself:

shlex.commenters:
    The string of characters that are recognized as comment beginners.
All characters from the comment beginner to end of line are ignored.
Includes just '#' by default.

----------
files: lexertest.py
messages: 93776
nosy: jjdmol2
severity: normal
status: open
title: shlex behaves unexpected if newlines are not whitespace
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15087/lexertest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Fri Oct  9 10:23:46 2009
From: report at bugs.python.org (Andy Balaam)
Date: Fri, 09 Oct 2009 08:23:46 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255076626.61.0.951000373867.issue6676@psf.upfronthosting.co.za>


Andy Balaam <mail at artificialworlds.net> added the comment:

I am also seeing this with Python 2.5.2 on Ubuntu.

----------
nosy: +andybalaam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 10:25:21 2009
From: report at bugs.python.org (Jan David Mol)
Date: Fri, 09 Oct 2009 08:25:21 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1255076721.06.0.498140253713.issue7089@psf.upfronthosting.co.za>


Jan David Mol <jjdmol at gmail.com> added the comment:

Attached is a patch which fixes this for me. It basically does a
fall-through using '\n' when encountering a comment. So that may be a
bit of a hack (who says '\n' is the only newline char in there, and not
'\r'?) but I'll leave the more intricate stuff to you experts.

----------
keywords: +patch
Added file: http://bugs.python.org/file15088/lexer-newline-tokens.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Fri Oct  9 10:26:51 2009
From: report at bugs.python.org (Andy Balaam)
Date: Fri, 09 Oct 2009 08:26:51 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255076811.85.0.3650893566.issue6676@psf.upfronthosting.co.za>


Andy Balaam <mail at artificialworlds.net> added the comment:

Just in case it wasn't obvious - the workaround is to create a new
parser (with xml.parsers.expat.ParserCreate()) for every XML file you
want to parse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 11:12:34 2009
From: report at bugs.python.org (Mahmoud)
Date: Fri, 09 Oct 2009 09:12:34 +0000
Subject: [issue7090] encoding uncode objects greater than FFFF
In-Reply-To: <1255079554.68.0.710322041436.issue7090@psf.upfronthosting.co.za>
Message-ID: <1255079554.68.0.710322041436.issue7090@psf.upfronthosting.co.za>


New submission from Mahmoud <saghaei at med.mui.ac.ir>:

Odd behaviour with str.encode or codecs.Codec.encode or simailar
functions, when dealing with uncode objects above ffff

with 2.6
>>> u'\u10380'.encode('utf')
'\xe1\x80\xb80'

with 3.x
'\u10380'.encode('utf')
'\xe1\x80\xb80'

correct output must be:
\xf0\x90\x8e\x80

----------
components: Unicode
messages: 93780
nosy: msaghaei
severity: normal
status: open
title: encoding uncode objects greater than FFFF
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7090>
_______________________________________

From report at bugs.python.org  Fri Oct  9 11:16:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Oct 2009 09:16:52 +0000
Subject: [issue7090] encoding uncode objects greater than FFFF
In-Reply-To: <1255079554.68.0.710322041436.issue7090@psf.upfronthosting.co.za>
Message-ID: <1255079812.41.0.900365039954.issue7090@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you want to specify codepoints greater than U+FFFF you have to use
u'\Uxxxxxxxx':
>>> x = u'\u10380'
>>> x.encode('utf-8')
'\xe1\x80\xb80'
>>> x[0]
u'\u1038'
>>> x[1]
u'0'
>>> y = u'\U00010380'
>>> y.encode('utf-8')
'\xf0\x90\x8e\x80'

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7090>
_______________________________________

From report at bugs.python.org  Fri Oct  9 11:41:02 2009
From: report at bugs.python.org (Jan David Mol)
Date: Fri, 09 Oct 2009 09:41:02 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1255081262.32.0.968681779219.issue7089@psf.upfronthosting.co.za>


Changes by Jan David Mol <jjdmol at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Fri Oct  9 11:45:55 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 09:45:55 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255081555.36.0.11237352695.issue6676@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'm not familiar with expat, but we can see what is happening more
clearly with attached adhok patch.

Traceback (most recent call last):
  File "expat-error.py", line 14, in <module>
    p.ParseFile(file)
xml.parsers.expat.ExpatError: parsing finished: line 2, column 482

It seems ParseFile() doesn't support second call. I'm not sure this is
intended behavior or not.

----------
keywords: +patch
nosy: +ocean-city
versions: +Python 2.7
Added file: http://bugs.python.org/file15089/pyexpat_addhok.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 12:53:42 2009
From: report at bugs.python.org (Darren Worrall)
Date: Fri, 09 Oct 2009 10:53:42 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255085622.44.0.826386771621.issue7082@psf.upfronthosting.co.za>


Darren Worrall <dw at darrenworrall.co.uk> added the comment:

Indeed, I'm certainly not constructing messages like that, but
occasionally have to process them :)

RE: the python versions, I'll remember that in future, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7082>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:03:06 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 09 Oct 2009 12:03:06 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255050832.92.0.0385139618703.issue7086@psf.upfronthosting.co.za>
Message-ID: <135596.64450.qm@web25808.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Which syslog daemon are you using? There are some issues pending with syslog-ng and Python logging (see issue6444) and in general syslog over TCP is not necessarily all that reliable, see

http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html

The requested change is not difficult to make, but it will be difficult for me to test because in general end-to-end testing for network APIs is not there in the standard regression test suite, and I don't have a setup where I can test it independently. So I'm sorry to say I will not be able to give this a very high priority at the moment (unless another committer can test this).

Just curious (as no one has asked for this before) why you're using TCP, given that it doesn't eliminate message loss and it is slower and has less support than UDP?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7086>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:04:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Oct 2009 12:04:58 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255089898.85.0.50907131156.issue6676@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is good; a test would be appreciated.

The difference now is that in case of true low-memory conditions,
ExpatError("no memory") is raised instead of MemoryError.
This is acceptable IMO.

> It seems ParseFile() doesn't support second call
This is correct; the C expat library has a function XML_ParserReset()
which could be called before calling ParseFile() again, but pyexpat does
not expose it yet (see issue1208730).

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:11:32 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Oct 2009 12:11:32 +0000
Subject: [issue1208730] expat binding for XML_ParserReset
Message-ID: <1255090292.05.0.972008680835.issue1208730@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This (old) patch needs some work:

- unit tests are neeeded.

- it it not enough to return NULL when XML_ParserReset() returns an
error; a python exception must be raised.

- "This function may not be used on a parser created using
XML_ExternalEntityParserCreate": if XML_ParserReset() does not check it
properly, we should ensure that an exception is properly raised.

- "How many of the struct elements do I need to reset?": this should be
worked out. And I'm not convinced that self->intern should be reset.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208730>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:14:06 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 12:14:06 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1255090446.57.0.453011167358.issue3210@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

No, this is not duplicate of issue5179. That issue described handle was
leaked when exception occurred. But this issue is not *leak*. See
following code.

import subprocess, os, sys
file = open("filename", "w")
try:
    proc = subprocess.Popen("nosuchprogram", stdout=file)
except OSError:
    file.close()
    sys.exc_clear() # here we go....
    os.remove("filename") # now we can delete file!

subprocess is implemented using sp_handle_type in PC/_subprocess.c
(windows). This object is in exception stack frame(?), so handle lives
until another exception occurs or explicitly sys.exc_clear() is called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:26:12 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 12:26:12 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1255091172.88.0.303670913413.issue3210@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Probably we can fix this issue by calling Close() of sp_handle_type
somewhere in Lib/subprocess.py, but I have no patch now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:27:01 2009
From: report at bugs.python.org (Martin Marcher)
Date: Fri, 09 Oct 2009 12:27:01 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1255091221.99.0.132683974577.issue5672@psf.upfronthosting.co.za>


Changes by Martin Marcher <martin at marcher.name>:


----------
nosy: +martin.marcher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Fri Oct  9 14:50:28 2009
From: report at bugs.python.org (jmb)
Date: Fri, 09 Oct 2009 12:50:28 +0000
Subject: [issue7091] Distutils build ignores the --compiler command line option
In-Reply-To: <1255092628.15.0.61454939103.issue7091@psf.upfronthosting.co.za>
Message-ID: <1255092628.15.0.61454939103.issue7091@psf.upfronthosting.co.za>


New submission from jmb <jeberger at free.fr>:

I tried building an extension on windows with the following command:

> python setup.py build --compiler=mingw32

and got an error: "Unable to find vcvarsall.bat". The way I understand
it, that error shows that it tried to use the MSVC compiler instead of
obeying the --compiler=mingw32 command line option.

I then tried to give a bogus compiler value and got the same error
message (iirc python 2.5 used to say that it didn't know the 'bogus'
compiler).

Finally, I modified _default_compilers in distutils/ccompiler.py and put
'mingw32' in the 'nt' key. Afterward, my extension compiled and works
properly.

Python version: 2.6.3 on WinXP 32 bits.

----------
assignee: tarek
components: Distutils
messages: 93789
nosy: jmb, tarek
severity: normal
status: open
title: Distutils build ignores the --compiler command line option
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7091>
_______________________________________

From report at bugs.python.org  Fri Oct  9 15:00:49 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 13:00:49 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255093249.08.0.948991670794.issue6676@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, I tried to write test like this.

1. Check if xml.parsers.expat.error is raised.
2. Compare *code* attribute of error object with
xml.parsers.expat.errors.XML_ERROR_FINISHED

But I noticed XML_ERROR_FINISHED is not integer but string. (!)

According to
http://docs.python.org/library/pyexpat.html#expaterror-objects

> ExpatError.code
>
>    Expat?s internal error number for the specific error. This will
>    match one of the constants defined in the errors object from
>    this module.

Is this document bug or implementation bug? Personally, I think string
'parsing finished' as error constant might be useless...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 15:12:13 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Oct 2009 13:12:13 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255093933.45.0.21515737338.issue6676@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Looks like an implementation bug to me; far too late to change it, though.

In your test, you could use
  pyexpat.ErrorString(e.code) == pyexpat.errors.XML_ERROR_FINISHED
And the docs could mention this trick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:04:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Oct 2009 14:04:59 +0000
Subject: [issue4428] make io.BufferedWriter observe max_buffer_size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1255097099.07.0.197875959598.issue4428@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

max_buffer_size is no longer used, so this issue is obsolete ;)

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:06:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Oct 2009 14:06:38 +0000
Subject: [issue4555] Smelly exports
In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za>
Message-ID: <1255097198.03.0.913756995837.issue4555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In trunk:

_add_one_to_index_C
_add_one_to_index_F
asdl_int_seq_new
asdl_seq_new
init_ast
init_codecs
initerrno
initgc
initimp
initposix
initpwd
initsignal
init_sre
init_symtable
initthread
initxxsubtype
initzipimport

In py3k:

_add_one_to_index_C
_add_one_to_index_F
asdl_int_seq_new
asdl_seq_new

----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4555>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:11:23 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 14:11:23 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255097483.17.0.0962747523933.issue6676@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is the patch. I'm not confident with my English comment though.

----------
Added file: http://bugs.python.org/file15090/pyexpat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:11:34 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 14:11:34 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255097494.54.0.424307166649.issue6676@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file15089/pyexpat_addhok.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:30:33 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 09 Oct 2009 14:30:33 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

If the test suite is run with -3, many deprecation warnings are
reported.  Quite a few are generated by code in the tests themselves,
but many are from constructs in the stdlib which are different or no
longer supported in 3.x.

Even aside from the fact that many of these warnings being caused by
code which I think many people would agree is not ideal, I think it is
important for these warnings to be fixed for Python 2.7.  Since the 3.x
porting guidelines recommend that projects first run their test suite
with -3, these warnings are going to be generating extra noise for
developers to filter through when they try porting their code to 3.x. 
They shouldn't need to wade through stdlib warnings to find warnings
about their own code.

Attached is a log of a complete test run with -3.

----------
components: Library (Lib)
files: test.log
messages: 93795
nosy: exarkun
severity: normal
status: open
title: Test suite emits many DeprecationWarnings when -3 is enabled
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15091/test.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:32:57 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Oct 2009 14:32:57 +0000
Subject: [issue7029] Improve pybench
In-Reply-To: <1254417403.92.0.577059221924.issue7029@psf.upfronthosting.co.za>
Message-ID: <1255098777.43.0.760431571963.issue7029@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Fixed the bug with "timer = timer" in trunk in revision 75293

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7029>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:40:25 2009
From: report at bugs.python.org (Simon Cross)
Date: Fri, 09 Oct 2009 14:40:25 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1255099225.2.0.892874267977.issue6280@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

The attached patch adds a simple implementation of time.timegm that
calls calendar.timegm. It includes a short test to show that 
time.timegm(time.gmtime(ts)) == ts for various timestamps.

I implemented a pure C version by pulling in the various functions
needed from datetime, but it was a bit messy and a lot more invasive.

Documentation updates are still needed -- I will do those if there is
support for the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file15092/add-timegm-to-time.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Fri Oct  9 16:55:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2009 14:55:48 +0000
Subject: [issue7093] xmlrpclib.ServerProxy() doesn't support unicode uri
In-Reply-To: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>
Message-ID: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I backported xmlrpclib from Python trunk to Python 2.5 to get "connected
socket" (HTTP/1.1), which implies to backport also httplib, ssl and socket. It
works well. It's *much* faster, eg. 960 ms => 70 ms with HTTPS over a VPN.

I just have a little issue: if ServerProxy() URI is an unicode string and an
argument is an unicode string (with at least one non-ASCII character), the
request fails with:

  File ".../SVN/python-trunk/Lib/httplib.py", line 784, in _send_output
    msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 320:
ordinal not in range(128)

Attached patch includes a test.

Can uri contains a login and/or pasword? If yes, should it be encoded to UTF-8
(instead of ASCII)?

----------
components: Library (Lib)
files: xmlrpclib_unicode_host.patch
keywords: patch
messages: 93798
nosy: haypo
severity: normal
status: open
title: xmlrpclib.ServerProxy() doesn't support unicode uri
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15093/xmlrpclib_unicode_host.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7093>
_______________________________________

From report at bugs.python.org  Fri Oct  9 17:00:29 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2009 15:00:29 +0000
Subject: [issue7093] xmlrpclib.ServerProxy() doesn't support unicode uri
In-Reply-To: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>
Message-ID: <1255100429.17.0.550255466403.issue7093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, it looks that the issue is not on ServerProxy.__host, but on
ServerProxy.__handler. That's why my test uses "http://host:port/RPC2" instead
of "http://host:port". In the second case, the handler is set to the default value:
"/RPC2" which is str (and not unicode).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7093>
_______________________________________

From report at bugs.python.org  Fri Oct  9 17:15:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Oct 2009 15:15:16 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255101316.06.0.892852223479.issue7092@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think it's so important that tests not raises -3 warnings, but
that the stdlib doesn't.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Oct  9 17:17:44 2009
From: report at bugs.python.org (Jr Aquino)
Date: Fri, 09 Oct 2009 15:17:44 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255101464.43.0.562400625865.issue7086@psf.upfronthosting.co.za>


Jr Aquino <jr.aquino at citrixonline.com> added the comment:

Thank you for responding so quickly Vinay.

I am using a multitude of syslog daemons, from syslog, syslog-ng, 
rsyslog, and several different proprietary SIEM/SEM Log archiving 
appliances.  I work in the security sector.

(Yes I have read Rainer before, its actually a big reason I am writing 
the tool that I am working on. Gaps in logs are a real world problem!) 

Regarding issue 6444, these users are attempting to use SysLogHandler to 
write to the local system's syslog sockets. A way of piggy backing on 
the configuration of the local systems logging daemon.

What I am actually doing is ignoring the local systems syslog, and 
sending the syslog packets directly to a remote syslog server. This is 
to replay syslog data that may have been previously lost due to 
connectivity outages.  My tool can also be used to send the data to an 
external server for forensic reasons.

I believe the answer to your last question also sheds light on your 
first question!

The reason that I am looking to add TCP is because a lot of new data 
center architectures are heavily utilizing tcp syslog in a chained / 
centralized environment.  I am also seeing a lot of preferential 
treatment of tcp syslog on logging appliances such as Loglogic.

I am sorry to hear that your test environment is lacking the regression 
suites that you need.

I do hope that another commiter can test for us.  Syslog is an old 
technology and I hope that more efforts like mine and Rainer's can help 
to identify and correct deficiencies in the design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7086>
_______________________________________

From report at bugs.python.org  Fri Oct  9 17:29:05 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Oct 2009 15:29:05 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255102145.91.0.0834839385368.issue6676@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do you know the new "context manager" feature of assertRaises? it makes
it easier to check for exceptions.
I join a new patch that uses it.

----------
Added file: http://bugs.python.org/file15094/pyexpat-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 17:44:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 15:44:54 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255103094.69.0.391756958248.issue6676@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I knew existence of that new feature, but didn't know how to use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 18:13:12 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 09 Oct 2009 16:13:12 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1255104792.34.0.00429257929344.issue6676@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hmm, looks useful. I think your patch is good. Only one problem is that
we cannot use this new feature in python2.6. If we use my patch in that
branch, I think there is no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Fri Oct  9 20:21:09 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2009 18:21:09 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255112469.37.0.920718878762.issue7092@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I agree with Benjamin. We shouldn't release 2.7 w/ any of the standard 
library itself generating a Py3kWarning, but that should not apply to the 
test suite.

I have made this a release blocker until we can create separate issues for 
the modules that are emitting the warning.

----------
nosy: +brett.cannon
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Oct  9 20:29:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Oct 2009 18:29:11 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255112951.83.0.19173860317.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

FWIW I tried to filter out the test-related warnings using the following
command line, but it didn't work (nothing was filtered out):

$ ./python -3 -W 'ignore::DeprecationWarning:test:0' -m test.regrtest

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Oct  9 21:54:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 09 Oct 2009 19:54:04 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Python's old-style formatting supports the use of an alternative form 
(specified by including a '#' in the format) for 'e', 'f' and 'g' 
formatting:

Python 3.2a0 (py3k:75275:75276, Oct  7 2009, 20:26:36) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '%.17g' % 1.2
'1.2'
>>> '%#.17g' % 1.2
'1.2000000000000000'

New-style formatting doesn't currently support this:

>>> format(1.2, '#.17g')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Alternate form (#) not allowed in float format specifier

To aid migration from old-style to new-style formatting, it might be worth 
adding the alternate forms.  At least the float, complex and Decimal types 
would be affected.

----------
components: Interpreter Core
messages: 93807
nosy: eric.smith, mark.dickinson
severity: normal
stage: test needed
status: open
title: Add alternate float formatting styles to new-style formatting.
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Fri Oct  9 21:58:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 09 Oct 2009 19:58:09 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1255118289.49.0.774362497058.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm adding 2.7. Since 2.7 and 3.2 share the same code base, I'd rather
add it to both if we're going to do it at all.

----------
assignee:  -> eric.smith
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Fri Oct  9 22:04:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 09 Oct 2009 20:04:18 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1255118658.63.0.913492013831.issue7094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just for reference, the effect of the alternative style is explained 
succinctly in the C99 standard (well, the N1256 draft, anyway):

"For a, A, e, E, f, F, g, and G conversions, the result of converting a 
floating-point number always contains a decimal-point character, even if 
no digits follow it. (Normally, a decimal-point character appears in the 
result of these conversions only if a digit follows it.) For g and G 
conversions, trailing zeros are not removed from the result. For other 
conversions, the behavior is undefined."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Fri Oct  9 23:44:58 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 09 Oct 2009 21:44:58 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255124698.57.0.39261960803.issue7086@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Jr Aquino: can you please test the attached alternative patch with all
the various syslog daemons in Unix domain, UDP and TCP socket
combinations, and post your results here? Thanks.

P.S. Also available colourised at http://gist.github.com/206380

----------
assignee:  -> vinay.sajip
status: open -> pending
Added file: http://bugs.python.org/file15095/sockhand.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7086>
_______________________________________

From report at bugs.python.org  Fri Oct  9 23:45:55 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 09 Oct 2009 21:45:55 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1255124755.33.0.945238185383.issue7077@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7077>
_______________________________________

From report at bugs.python.org  Fri Oct  9 23:47:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2009 21:47:16 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255124836.14.0.623154419223.issue7082@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7082>
_______________________________________

From report at bugs.python.org  Sat Oct 10 01:06:57 2009
From: report at bugs.python.org (Jr Aquino)
Date: Fri, 09 Oct 2009 23:06:57 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255129617.62.0.159320747842.issue7086@psf.upfronthosting.co.za>


Jr Aquino <jr.aquino at citrixonline.com> added the comment:

Vinay, tested on all syslog daemons/servers.  Works perfectly.

Thank you very much. I appreciate your time greatly.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7086>
_______________________________________

From report at bugs.python.org  Sat Oct 10 01:13:18 2009
From: report at bugs.python.org (schlesin)
Date: Fri, 09 Oct 2009 23:13:18 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>


New submission from schlesin <schlesin at cshl.edu>:

The documentation for the Multiprocessing.Array says:

multiprocessing.Array(typecode_or_type, size_or_initializer, *,
lock=True)?

...
If lock is False then access to the returned object will not be
automatically protected by a lock, so it will not necessarily be
?process-safe?.
...

However:
In [48]: mp.Array('i',1,lock=False)
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call
last)

/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
multiprocessing/__init__.pyc in Array(typecode_or_type,
size_or_initializer, **kwds)
    252     '''
    253     from multiprocessing.sharedctypes import Array
--> 254     return Array(typecode_or_type, size_or_initializer,
**kwds)
    255
    256 #

/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
multiprocessing/sharedctypes.pyc in Array(typecode_or_type,
size_or_initializer, **kwds)
     85     if lock is None:
     86         lock = RLock()
---> 87     assert hasattr(lock, 'acquire')
     88     return synchronized(obj, lock)
     89

AssertionError:

-------
I.e. it looks like lock=False is not actually supported.

----------
components: Extension Modules
messages: 93812
nosy: schlesin
severity: normal
status: open
title: Multiprocessing.Array(lock=False) fails
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 01:47:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Oct 2009 23:47:47 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255132067.19.0.451936564828.issue7095@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 01:53:02 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 09 Oct 2009 23:53:02 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255132382.27.0.0609526820778.issue7095@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

schlesin - what platform are you on, and what version of 2.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 02:12:18 2009
From: report at bugs.python.org (schlesin)
Date: Sat, 10 Oct 2009 00:12:18 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255133538.06.0.754814796889.issue7095@psf.upfronthosting.co.za>


schlesin <schlesin at cshl.edu> added the comment:

Happens both on
Python 2.6 (r26:66714, Jul 25 2009, 11:30:23) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
and
Python 2.6.1 (r261:67515, Dec  6 2008, 16:42:21) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 02:55:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Oct 2009 00:55:11 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255136111.96.0.0260334808461.issue7060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin tried reverting the weakref patch, but that didn't fix it. 
Turns out the problem is the other patch in that merge, that adds saving
of the exception to AssertRaises.  Adding Kristjan as that was his patch.
(The tests pass with the weakref patch applied and the unittest patch
reverted, by the way.)

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sat Oct 10 03:08:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Oct 2009 01:08:05 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1255136885.36.0.0277150922796.issue7082@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied to trunk in r75301, py3k in r75307, and 3.1 in r75308.  Leaving
open until I can backport it to 2.6.  Thanks, Darren.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7082>
_______________________________________

From report at bugs.python.org  Sat Oct 10 04:40:29 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 10 Oct 2009 02:40:29 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255142429.79.0.892944338729.issue7095@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Fixed in r68708 - upgrading to 2.6.2 should solve this.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 04:53:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Oct 2009 02:53:54 +0000
Subject: [issue7096] test_curses fails on 3.1 when run under regrtest
In-Reply-To: <1255143233.91.0.954013064992.issue7096@psf.upfronthosting.co.za>
Message-ID: <1255143233.91.0.954013064992.issue7096@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

test_curses currently fails on 3.1 when run under regrtest.  It passes
if run in verbose mode or standalone.  The cause turns out to be that
when not run in verbose mode regrtest substitutes an io.StringIO
instance for sys.stdout, and that object does not have a .fileno
attribute.  The line that fails is this:

curses.setupterm(fd=sys.stdout.fileno())

This test fails only on 3.1 for a couple of different reasons.  On trunk
and py3k, r73072 and the r73678 merge removed the regrtest check that
made sure the tests produced no output on stdout, and therefore it no
longer replaces stdout with a StringIO instance .  On 2.6, on the other
hand, the above line references sys.__stdout__.fileno() (presumably for
this very reason!)  r74181 was the commit that changed this to the above
on the py3k branch, citing it as the cause of regrtest "duplicating some
output".

It seems to me that not checking for output on stdout in regrtest is a
regression in the quality of the test runner.  It is also not clear to
me how test_curses writing to the real stdout would cause regrtest to
duplicate output.  So I'm putting the authors of the two patches
involved on the nosy list so they can comment.  FYI I reverted the
stdout change in test_curses and regrtest seems to run fine, so I'm not
sure what output was being duplicated.

----------
components: Tests
messages: 93818
nosy: alexandre.vassalotti, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_curses fails on 3.1 when run under regrtest
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7096>
_______________________________________

From report at bugs.python.org  Sat Oct 10 04:58:27 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 10 Oct 2009 02:58:27 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255143507.87.0.708798053109.issue7095@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Gabriel is right, I'm really hoping Apple includes an upgrade including 
2.6.4 once it's buttoned down

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 04:58:41 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 10 Oct 2009 02:58:41 +0000
Subject: [issue7095] Multiprocessing.Array(lock=False) fails
In-Reply-To: <1255129998.33.0.0350728578751.issue7095@psf.upfronthosting.co.za>
Message-ID: <1255143521.69.0.0210163123576.issue7095@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7095>
_______________________________________

From report at bugs.python.org  Sat Oct 10 05:15:31 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 10 Oct 2009 03:15:31 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1255144531.53.0.486662649409.issue7089@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

If you could add some tests to lib/test/test_shlex.py, there are more 
chances for this patch to be accepted.

Also, consider the case when the comment is on the last line of input 
and there is no \n ending character.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Sat Oct 10 06:05:38 2009
From: report at bugs.python.org (schlesin)
Date: Sat, 10 Oct 2009 04:05:38 +0000
Subject: [issue6653] Potential memory leak in multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1255147538.7.0.835669844017.issue6653@psf.upfronthosting.co.za>


Changes by schlesin <schlesin at cshl.edu>:


----------
nosy: +schlesin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Sat Oct 10 06:09:53 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sat, 10 Oct 2009 04:09:53 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1255147793.0.0.346843377439.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

I've run into an additional problem with these patches. While they 
correctly set up the menus for Python Shell and editor windows, when a 
front-most window is closed, the menubar suddenly displays duplicate 
entries (for Edit, Run, and Help) at the end of the menubar, not all of 
which work correctly. Subsequent closing of other windows causes more 
duplication of menu entries. I have looked at every line of these patches, 
as well as some additional points in idlelib, and I cannot find what is 
causing the issue. As a result, I don't know where to fix it. If others 
are able to reproduce this bug after applying the patches and can find 
where the problem is occurring, suggestions (or a fix) are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Sat Oct 10 08:39:32 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 10 Oct 2009 06:39:32 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1255156772.14.0.687310919076.issue1724822@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

FYI I've implemented a Windows command line parser for use by subprocess 
on Jython, it's available here:

http://fisheye3.atlassian.com/browse/jython/trunk/jython/Lib/subprocess.
py?r=6636#l554

tests:

http://fisheye3.atlassian.com/browse/jython/trunk/jython/Lib/test/test_s
ubprocess_jy.py?r=6464#l41

like shlex, it wasn't built to handle ; && || to join multiple commands 
as #1521950 requests. But other than that it's complete

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Sat Oct 10 10:06:43 2009
From: report at bugs.python.org (Michael Wise)
Date: Sat, 10 Oct 2009 08:06:43 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1254992174.81.0.402880358162.issue4064@psf.upfronthosting.co.za>
Message-ID: <4AD04089.7050803@uwa.edu.au>


Michael Wise <Michael.Wise at uwa.edu.au> added the comment:

Dear Ronald

Not that simple. I had, for the first time, installed Python 2.6.3 via 
the .dmg rather than compiled from scratch, and then numpy, again via 
the .dmg. I was trying to compile biopython from scratch using disutils 
when the problem occurred. That was on a G4 PPC Mac laptop. On a 
different G5 PPC  PowerMac, I did the whole job from scratch and all was 
well.

I can confirm that get_platform was not the problem (check it 
specifically) and I got something to work by modifying the 
config/Makefile, but then worried about what else that would affect. I 
removed the .dmg supplied Python and numpy, and installed Python 2.6.3 
from scratch, but had problem of the disutils installation of numpy 
hanging, so I removed that and did the whole job based on the previous 
installation 2.5.2.

Cheers
MichaelW

Ronald Oussoren wrote:
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> Michael: please file a new issue for this, your problem seems to be 
> unrelated to this one.
> 
> In that issue include information about:
> 
> 1) The python version you are using
> 2) The version of MacOSX
> 3) The version of Xcode (open /Developer/Applications/Xcode.app,
>     check the version in the About dialog)
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4064>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sat Oct 10 11:24:35 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Oct 2009 09:24:35 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1255166675.65.0.644189053263.issue4064@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ...
>
>followed, unsurprisingly, by:
>gcc-4.0: installation problem, cannot exec
>'i686-apple-darwin8-gcc-4.0.0': No such file or directory

>From at least OS X 10.4 on, Xcode installs both variants of compilers so 
it is possible to build both Intel and PPC archs on any system.  I 
regularly build complete fat Python installers on a PPC G3 running 10.4.

$ uname -p
powerpc
$ i686-apple-darwin8-gcc-4.0.1 
i686-apple-darwin8-gcc-4.0.1: no input files

Was this possibly on an older version of OS X, say 10.3?  Otherwise, it 
sounds like that system did not have a complete installation of Xcode 
somehow.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sat Oct 10 13:04:37 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 10 Oct 2009 11:04:37 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255172677.8.0.26397501191.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Interesting.  I don't have a linux machine to debug this.  My patch 
appears harmless enough.  We are only storing an exception _object_, not 
any tracebacks or such.
If this were happening on my windows machine I would put in breakpoints 
where the ignored assertion is being raised and find out what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sat Oct 10 13:54:38 2009
From: report at bugs.python.org (Michael Wise)
Date: Sat, 10 Oct 2009 11:54:38 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1255166675.65.0.644189053263.issue4064@psf.upfronthosting.co.za>
Message-ID: <4AD075F5.5060706@uwa.edu.au>


Michael Wise <Michael.Wise at uwa.edu.au> added the comment:

Dear Ned

Odd you should say that. The system is the latest version of 10.4 
(10.4.11),  but I did notice that the compiler assumed 10.3. The version 
  of Xcode on this PowerBook G4 is 2.0 (quite old), so perhaps it has 
OSX 10.3 wired in. I don't think that was the issue, but to eliminate it 
I'll download Xcode when I'm at work on Monday (better bandwidth) and 
see if that does a better job.

Cheers (and thanks!)
Michael

Ned Deily wrote:
> Ned Deily <nad at acm.org> added the comment:
> 
>> gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ...
>>
>> followed, unsurprisingly, by:
>> gcc-4.0: installation problem, cannot exec
>> 'i686-apple-darwin8-gcc-4.0.0': No such file or directory
> 
>>From at least OS X 10.4 on, Xcode installs both variants of compilers so 
> it is possible to build both Intel and PPC archs on any system.  I 
> regularly build complete fat Python installers on a PPC G3 running 10.4.
> 
> $ uname -p
> powerpc
> $ i686-apple-darwin8-gcc-4.0.1 
> i686-apple-darwin8-gcc-4.0.1: no input files
> 
> Was this possibly on an older version of OS X, say 10.3?  Otherwise, it 
> sounds like that system did not have a complete installation of Xcode 
> somehow.
> 
> ----------
> nosy: +ned.deily
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4064>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sat Oct 10 14:41:34 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Oct 2009 12:41:34 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1255178494.1.0.933440765265.issue7055@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm glad someone with more roundtuits than I had the same idea after the
logging error in 2.6.3 :)

The regrtest change isn't needed any more since RDM checked that concept
in separately - the test update itself looks fine though (and applies
and runs cleanly on the trunk).

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7055>
_______________________________________

From report at bugs.python.org  Sat Oct 10 15:24:51 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Oct 2009 13:24:51 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1255181091.27.0.310009136208.issue6763@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The thread safety problem comes from the fact that performing file IO as
mimetypes.init() does will release the GIL - if you want to ensure
thread safety in that context, you have to do your own locking.
mimetypes ignore this thread syncrhonisation problem completely with
unhelpful results.

An attempt was made to address the race condition in r72045 by
eliminating the infinite recursion. Instead, you just get init() being
invoked multiple times on different MimeTypes instances, with the last
one "winning" and being kept as the _db module global (which does
eliminate the crash, but has problems of its own).

This crash probably involves hitting the recursion limit and that's
always a bit dicey as to whether we actually manage to trap it before
the C stack goes boom. With this case being an infinite recursion in an
__init__() method leading to an infinite number of a given object type
being allocated, that's a bit special since it raises the prospect of
potentially running out of heap memory (although that's unlikely with
the default recursion limit unless there are an awful lot of threads
involved).

To check the simple failure mechnism, I tried threading out the following:

class Broken():
  def __init__(self):
    break_it()

def break_it():
  Broken()

from threading import Thread
threads = [Thread(target=break_it) for x in range(100)]
for t in threads: t.start()

On my machine, the threads fail with "RuntimeError: maximum recursion
depth exceeded" for a recursion limit of 1000 or 10000, but segfault at
100,000. However, the 100k recursion limit segfaults even if I only use
a single thread (i.e. call break_it() directly without involving the
threading module at all).

For the OP:

What value do you get for sys.getrecursionlimit()?
Do you still get the segfault if you use sys.setrecursionlimit() to
lower the maximum allowed level of recursion? (e.g. limit it to 200 or
500 recursions)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sat Oct 10 16:38:52 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Oct 2009 14:38:52 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1255185532.97.0.204069134924.issue6626@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Putting this here for the record rather than leaving it in Rietveld:

I appreciate the desire for a cleaner API for handling mimetypes, but
this isn't the way to get it. Finding projects that have their own
mimetypes implementations, asking them why they created their own rather
than using the standard one, seeing what features are common to those
APIs, etc, are all things that need to be done before making major
changes to the standard library API.

What you see as a critical bug (custom MimeTypes instances inheriting
their initial settings from the mimetypes._db instance), you can bet
some developers are relying on as a feature. If code is in the standard
library, someone, somewhere, is relying on it working just the way it is
now. Even bug fixes can sometimes break code that was designed to work
around the presence of the bug.

The concept of having a master copy that new instances are cloned from
isn't even particularly objectionable, so long as people clearly
understand that is what is going on (e.g. this happens with
decimal.DefaultContext being used as the basis for new decimal.Context
instances).

With code this old, 'softly, softly' is the way to go, and the fewer
user visible changes in semantics the better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sat Oct 10 17:46:58 2009
From: report at bugs.python.org (Leonardo Santagada)
Date: Sat, 10 Oct 2009 15:46:58 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1255189618.07.0.218756529682.issue6763@psf.upfronthosting.co.za>


Leonardo Santagada <santagada at gmail.com> added the comment:

I'm on os x 10.6 where threadboom.py doesn't segfault anymore at least
on the system provided python. The problem that I see is that it
shouldn't be segfaulting on mac os x 10.5 with the default recursion
limit (I think it is 1000) with 2 threads. IIRC in a simple recursive
function (not on object __init__ like you did) I could put 10000 or more
as a recursion limit and still get a traceback, so I thought that 2
threads each with 1000 recursion limit should not be using the whole
stack. Also I think I did try to raise the stack limit with ulimit, but
I could be wrong.

Nick Coghlan, did you do your experments on os x 10.5? Can you try
threadboom.py on a python before the corrected mimetype lib landed
(somewhere between 2.6.2 and 2.6.3) or with an old version of the
mimetype lib?

I got the same errors both on my old white macbook core duo machine and
with a macbook pro core 2 duo and with both python 2.6.2 or 2.6.3 with
the old mimetypes lib.

I was worried with this bug because I guessed that maybe there is a race
condition of some sort on object creation on python 2.6. If someone can
reproduce the bug and understand the bug tell me it is a problem of
stack size I would rest my case and be happy with the segfault :).

ps: I will try to compile python2.6.2 here and reproduce the errors, if
I can I will reply with more info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sat Oct 10 17:53:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 10 Oct 2009 15:53:32 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1255190012.7.0.404008124567.issue4064@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Michael: Again, please file a new issue for your problem because it is not 
related to this one.

I'm removing myself from the nosy-list for this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sat Oct 10 17:55:25 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 10 Oct 2009 15:55:25 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1255190125.32.0.0564562953228.issue6075@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I have tried to apply the patches to python's trunk, but they don't apply 
cleanly at all.

Could you please rework the patches into a single larger patch that 
applies to the trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:41:16 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Oct 2009 16:41:16 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1255192876.39.0.456505515658.issue6763@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Knew I forgot to mention something - I'm not on OS X at all (Linux,
Ubuntu 8.04). I was only looking at this bug because RDM cross-linked it
to the mimetypes patch I was reviewing this evening.

Running the threadboom code, it passes fine for me on all of SVN head,
the 2.6 maintenance branch and the system Python (2.5.2).

I've added the OS X maintainer to the nosy list.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:40:15 2009
From: report at bugs.python.org (steve steiner)
Date: Sat, 10 Oct 2009 17:40:15 +0000
Subject: [issue7097] urlparse.urljoin of simple "http://" and "somedomain.com"
	produces incorrect result
In-Reply-To: <1255196414.88.0.948496525016.issue7097@psf.upfronthosting.co.za>
Message-ID: <1255196414.88.0.948496525016.issue7097@psf.upfronthosting.co.za>


New submission from steve steiner <ssteiner at users.sourceforge.net>:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from urlparse import urljoin
>>> urljoin("http://", "somedomain.com")
'http:///somedomain.com'

Note the three leading slashes, should be "http://somedomain.com"

----------
components: Library (Lib)
messages: 93834
nosy: ssteiner
severity: normal
status: open
title: urlparse.urljoin of simple "http://" and "somedomain.com" produces incorrect result
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7097>
_______________________________________

From report at bugs.python.org  Sat Oct 10 20:22:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Oct 2009 18:22:12 +0000
Subject: [issue7098] g formatting for decimal types should always strip
	trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Type 'g' formatting for Decimal instances doesn't behave in the same way 
as for floats when an explicit precision is given.  It should strip all 
trailing zeros from the result:

Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> format(Decimal('123.00'), '.6g')  # expect '123'
'123.00'

(When no explicit precision is given, Decimal formatting with type 'g' 
tries to preserve the information about the exponent of the Decimal 
instance whenever possible;  this also differs from float formatting, but 
it's intentional.  This should probably be documented.)

----------
assignee: mark.dickinson
components: Library (Lib)
messages: 93835
nosy: mark.dickinson
priority: normal
severity: normal
stage: test needed
status: open
title: g formatting for decimal types should always strip trailing zeros.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7098>
_______________________________________

From report at bugs.python.org  Sat Oct 10 20:26:35 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Oct 2009 18:26:35 +0000
Subject: [issue7097] urlparse.urljoin of simple "http://" and "somedomain.com"
	produces incorrect result
In-Reply-To: <1255196414.88.0.948496525016.issue7097@psf.upfronthosting.co.za>
Message-ID: <1255199195.99.0.148753352829.issue7097@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

urlparse.urljoin() is meant to join together a base URL with other URL 
parts. The protocol is part of the base URL and thus not supported by 
urlparse.urljoin().

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7097>
_______________________________________

From report at bugs.python.org  Sat Oct 10 20:39:54 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sat, 10 Oct 2009 18:39:54 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1255199994.79.0.0319946700032.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Single revised diff, "tkcocoa.diff", attached, applied against Python 
trunk. Have not tested against Python trunk, nor do I believe it solves 
the issue with the extra menu items appearing when a window is closed. But 
hopefully this will apply more cleanly.

----------
Added file: http://bugs.python.org/file15096/tkcocoa.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Sat Oct 10 20:45:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Oct 2009 18:45:23 +0000
Subject: [issue7099] Decimal.is_normal should return True even for numbers
	with exponent > Emax
In-Reply-To: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>
Message-ID: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Noticed by Stefan Krah:

Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> x = Decimal('9.99999999e+1000')
>>> c = getcontext()
>>> c.prec = 9
>>> c.Emax = 999
>>> c.Emin = -999
>>> 
>>> x.is_normal()
False
>>> x.is_subnormal()
False
>>> x.is_infinite()
False
>>> x.is_nan()
False
>>> x.is_zero()
False

So if x isn't normal, subnormal, zero, nan or infinity, what the ****
is it?!

x.is_normal() should probably be returning True here.

----------
assignee: mark.dickinson
components: Library (Lib)
messages: 93838
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Decimal.is_normal should return True even for numbers with exponent > Emax
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7099>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:14:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Oct 2009 19:14:49 +0000
Subject: [issue7098] g formatting for decimal types should always strip
	trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1255202089.49.0.572122971321.issue7098@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for trunk.

----------
keywords: +patch
nosy: +eric.smith
stage: test needed -> patch review
Added file: http://bugs.python.org/file15097/issue7098.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7098>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:28:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Oct 2009 19:28:52 +0000
Subject: [issue7098] g formatting for decimal types should always strip
	trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1255202932.85.0.142010342432.issue7098@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It should strip all trailing zeros from the result:

Hmm.  Thinking about this some more, I don't think this is true:  format() shouldn't be throwing away significant information (in Decimal 
the number of trailing zeros *is* significant information) unless that's 
necessary to fit the result into the given precision.

So I think the current code is correct.

However, we could do with documenting the precise rules being used for 
Decimal formatting somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7098>
_______________________________________

From report at bugs.python.org  Sat Oct 10 22:11:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Oct 2009 20:11:35 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1255205495.53.0.134284426461.issue1625@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As far as I can tell, the patch looks mostly good.
I just wonder, in Util_HandleBZStreamEnd(), why you don't set self->mode
to MODE_CLOSED if BZ2_bzReadOpen() fails.

As a sidenote, the bz2 module implementation seems to have changed quite
a bit between trunk and py3k, so if you want it to be backported to
trunk (2.7), you'll have to provide a separate patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sat Oct 10 22:34:10 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 10 Oct 2009 20:34:10 +0000
Subject: [issue7086] logging.handlers.SysLogHandler with TCP support
In-Reply-To: <1255042702.01.0.583220136591.issue7086@psf.upfronthosting.co.za>
Message-ID: <1255206850.81.0.187172883885.issue7086@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and py3k.

----------
resolution:  -> fixed
stage: test needed -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7086>
_______________________________________

From report at bugs.python.org  Sat Oct 10 22:39:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Oct 2009 20:39:30 +0000
Subject: [issue7100] test_xmlrpc: global name 'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This happens at least on the py3k branch, I haven't checked other branches.


test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
344, in tearDown
    stop_serving()
NameError: global name 'stop_serving' is not defined

1 test failed:
    test_xmlrpc
Unhandled exception in thread started by <bound method Thread._bootstrap
of <Thread(Thread-13, started 140424593951056)>>
Error in sys.excepthook:
TypeError: 'NoneType' object is not callable

Original exception was:
Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
282, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
308, in process_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
321, in finish_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
639, in __init__
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
693, in finish
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 242, in close
AttributeError: 'NoneType' object has no attribute 'RawIOBase'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
294, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
267, in handle_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
284, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
340, in handle_error
ImportError: No module named traceback

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
297, in http_server
AttributeError: 'NoneType' object has no attribute 'timeout'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 509,
in _bootstrap_inner
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 462,
in run
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
300, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 178, in close
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 173, in
_real_close
AttributeError: 'NoneType' object has no attribute 'socket'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 527,
in _bootstrap_inner
AttributeError: 'Thread' object has no attribute '_exc_info'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 482,
in _bootstrap
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 557,
in _bootstrap_inner
AttributeError: __exit__
[101191 refs]

1 test failed:
    test_xmlrpc
Unhandled exception in thread started by <bound method Thread._bootstrap
of <Thread(Thread-13, started 140014861584720)>>
Error in sys.excepthook:
TypeError: 'NoneType' object is not callable

Original exception was:
Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
282, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
308, in process_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
321, in finish_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
639, in __init__
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
693, in finish
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 242, in close
AttributeError: 'NoneType' object has no attribute 'RawIOBase'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
294, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
267, in handle_request
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
284, in _handle_request_noblock
  File "/home/antoine/py3k/bz-multistream/Lib/socketserver.py", line
340, in handle_error
ImportError: No module named traceback

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
297, in http_server
AttributeError: 'NoneType' object has no attribute 'timeout'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 509,
in _bootstrap_inner
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 462,
in run
  File "/home/antoine/py3k/bz-multistream/Lib/test/test_xmlrpc.py", line
300, in http_server
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 178, in close
  File "/home/antoine/py3k/bz-multistream/Lib/socket.py", line 173, in
_real_close
AttributeError: 'NoneType' object has no attribute 'socket'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 527,
in _bootstrap_inner
AttributeError: 'Thread' object has no attribute '_exc_info'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 482,
in _bootstrap
  File "/home/antoine/py3k/bz-multistream/Lib/threading.py", line 557,
in _bootstrap_inner
AttributeError: __exit__
[101191 refs]

----------
assignee: krisvale
components: Tests
messages: 93843
nosy: krisvale, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_xmlrpc: global name 'stop_serving' is not defined
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7100>
_______________________________________

From report at bugs.python.org  Sat Oct 10 23:27:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Oct 2009 21:27:20 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1255210040.3.0.721839410983.issue7055@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r75312, r75314. I'm not sure this should be backported to
2.6 and 3.1 (although it might be useful).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7055>
_______________________________________

From report at bugs.python.org  Sun Oct 11 01:49:22 2009
From: report at bugs.python.org (Denis Martinez)
Date: Sat, 10 Oct 2009 23:49:22 +0000
Subject: [issue7101] tarfile: OSError with TarFile.add(...,
	recursive=True) about non-existing file
In-Reply-To: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>
Message-ID: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>


New submission from Denis Martinez <deuns.martinez at gmail.com>:

I have written a server backup script (file attached) which archives a
list of directories with tarfile and uploads the file to FTP. Today, the
script hanged, with an exception:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
    self.run()
  File "./backup.py", line 48, in run
    tar.add(file_or_directory, recursive=True)
  File "/usr/lib/python2.6/tarfile.py", line 1981, in add
    self.add(os.path.join(name, f), os.path.join(arcname, f), recursive,
exclude)
  File "/usr/lib/python2.6/tarfile.py", line 1965, in add
    tarinfo = self.gettarinfo(name, arcname)
  File "/usr/lib/python2.6/tarfile.py", line 1834, in gettarinfo
    statres = os.lstat(name)
OSError: [Errno 2] No such file or directory: '/srv/myfile.htdigest'

What I did here is that I removed the htdigest file while the tarfile
was archiving /srv. I haven't managed to reproduce the bug a second time.
It seems normal that tarfile shouldn't fail is this case; maybe it needs
some exception checking around the stat/lstat calls.

----------
components: Library (Lib)
files: backup2.py
messages: 93845
nosy: denis
severity: normal
status: open
title: tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15098/backup2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7101>
_______________________________________

From report at bugs.python.org  Sun Oct 11 02:44:42 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 11 Oct 2009 00:44:42 +0000
Subject: [issue7084] printing a list releases the GIL carelessly
In-Reply-To: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>
Message-ID: <1255221882.68.0.274450186567.issue7084@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I've attached a patch that fixes this issue by grabbing a reference to
the item to be printed just before releasing the GIL.

----------
keywords: +patch
nosy: +scott.dial
Added file: http://bugs.python.org/file15099/list_print-r75317.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7084>
_______________________________________

From report at bugs.python.org  Sun Oct 11 03:57:45 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 11 Oct 2009 01:57:45 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1255226265.66.0.202388246458.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks to some hints by eric.smith, I've run the regression tests with
this patch applied. It turns out there are still some outstanding issues
with draft 9.

One issue was in test_glob.py where broken symlinks would fail to be
matched by glob. This was due to the fact that lexists still needed to
be implemented in ntpath.py. Draft 10 includes this capability.

Another problem the regression tests elicited is more insidious. The
patch breaks test_os.test_1686475, which references issue1686475. The
new symlink-aware stat must traverse symlinks. Unfortunately, the
current method of resolving the symlink target (as recommended by
Microsoft) fails to work if the symlink target is in use (or otherwise a
handle cannot be obtained). Unfortunately, it's not possible to call
GetFinalPathNameByHandle without a handle, the same way as issue1686475
was addressed by using a different API call.

I'm still devising a workaround for this undesirable behavior, but I
wanted to report that progress is still being made and I wanted to
capture the intermediate patch for posterity.

Stay tuned for more info.

----------
Added file: http://bugs.python.org/file15100/windows symlink draft 10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Oct 11 04:02:57 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 11 Oct 2009 02:02:57 +0000
Subject: [issue6894] urllib2 doesn't respect "no_proxy" environment
	(python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1255226577.72.0.31162469078.issue6894@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in trunk and Committed revision 75333.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6894>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:52:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Oct 2009 05:52:12 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1255240332.19.0.620042280994.issue4064@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy:  -loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:58:55 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 11 Oct 2009 05:58:55 +0000
Subject: [issue6894] urllib2 doesn't respect "no_proxy" environment
	(python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1255240735.1.0.385851156023.issue6894@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged into py3k revision 75334
merged into release-26maint revision 75335.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6894>
_______________________________________

From report at bugs.python.org  Sun Oct 11 08:08:54 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 11 Oct 2009 06:08:54 +0000
Subject: [issue6894] urllib2 doesn't respect "no_proxy" environment
	(python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1255241334.66.0.0725986001142.issue6894@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged in release31-maint in revision 75336

Closing the issue.

----------
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6894>
_______________________________________

From report at bugs.python.org  Sun Oct 11 12:56:05 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 11 Oct 2009 10:56:05 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1255258565.23.0.688681482947.issue4064@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy:  -ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sun Oct 11 13:16:07 2009
From: report at bugs.python.org (Fredrik Hedman)
Date: Sun, 11 Oct 2009 11:16:07 +0000
Subject: [issue7102] Problems building pyhton from source on Snow Leopard (Mac
	OS X 10.6)
In-Reply-To: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>
Message-ID: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>


New submission from Fredrik Hedman <fredrik.hedman at me.com>:

-*- mode: outline -*-

* Problems building pyhton from source on Snow Leopard (Mac OS X 10.6)
  1 error and 39 warnings and a quick fix.
** Building python from source with --enable-framework
I have a fresh install of Snow Leopard and the accompanying Xcode 3.2;
see below for platform details. I'm trying to build python from
Python-3.1.1.tar.bz2. The build

   $ export MACOSX_DEPLOYMENT_TARGET=10.6
   $ ./configure  --enable-framework
   $ make

fails with the following error:

   gcc  -framework CoreFoundation Python.framework/Versions/3.1/Python -
o python \
			   Modules/python.o \
			   Python.framework/Versions/3.1/Python -ldl
   ld: warning: in Python.framework/Versions/3.1/Python, file is not of 
required architecture
   ld: warning: in Python.framework/Versions/3.1/Python, file is not of 
required architecture
   Undefined symbols:
     "_PyMem_Malloc", referenced from:
	 _main in python.o
	 _main in python.o
	 _main in python.o
	 _main in python.o
     "_Py_Main", referenced from:
	 _main in python.o
	 _main in python.o
     "_PyMem_Free", referenced from:
	 _main in python.o
	 _main in python.o
	 _main in python.o
	 _main in python.o
   ld: symbol(s) not found
   collect2: ld returned 1 exit status
   make: *** [python] Error 1

** Error analysis and quick fix
The symbols above that are not defined are all defined in the library 
built
before the error occurs: libpython3.1.a. For some reason configure
does not include this library when linking.

Looking at the generated Makefile and the rule BUILDPYTHON one sees
that BLDLIBRARY seems to be not set properly.  If I tweak the Makefile 
and set

   BLDLIBRARY=     -L. $(LIBRARY)

then relaunching make works just fine.  The failed rule above
completes just fine and make completes without error.  

** 39 warnings and "file is not of required architecture"?
The results are not flawless since there are some complaints:

   Python build finished, but the necessary bits to build these modules 
were not found:
   ossaudiodev        spwd
   To find the necessary bits, look in setup.py in detect_modules() for 
the module's name.

   Failed to build these modules:
   _curses            _curses_panel

I choose to ignore these missing bits along with the other 39 warnings
generated during the build.  Most seem to be about quality of code.
The most worrying is the one about

   ld: warning: in Python.framework/Versions/3.1/Python, file is not of 
required architecture

which I do not really understand at this point, being quite new to
Cocoa and frameworks.

** Testing
make test reports:

    test_zlib
    310 tests OK.
    1 test failed:
	test_telnetlib
    24 tests skipped:
	test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
	test_codecmaps_kr test_codecmaps_tw test_curses test_epoll
	test_largefile test_nis test_normalization test_ossaudiodev
	test_pep277 test_smtpnet test_socketserver test_startfile
	test_timeout test_tk test_ttk_guionly test_urllib2net
	test_urllibnet test_winreg test_winsound test_xmlrpc_net
	test_zipfile64
    Those skips are all expected on darwin.

So the quick fix should be acceptable.

* A more permanent fix?  Needs verification
In file configure.in change (line 674)
      BLDLIBRARY=''
to
      BLDLIBRARY='-L. -lpython$(VERSION)'

Then generate a new configure script with

    autoreconf
    ./configure MACOSX_DEPLOYMENT_TARGET=10.6 --enable-framework
    make && make test

This seems to work fine, but must to be verified by someone with more
Cocoa and Framework knowledge since it sort of goes against the comments
that precede the changed line in configure.in.

* Platform
   $ uname -a
   Darwin beech.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 
22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386
   $ xcode-select -version
   xcode-select version 895.

----------
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 93851
nosy: FredrikHedman, ronaldoussoren
severity: normal
status: open
title: Problems building pyhton from source on Snow Leopard (Mac OS X 10.6)
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7102>
_______________________________________

From report at bugs.python.org  Sun Oct 11 13:36:43 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 11 Oct 2009 11:36:43 +0000
Subject: [issue7102] Problems building pyhton from source on Snow Leopard (Mac
	OS X 10.6)
In-Reply-To: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>
Message-ID: <1255261003.06.0.184280517732.issue7102@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fredrik: OSX 10.6 was released after Python 3.1.1. I know that we had to 
apply a number of patches to the 2.6 branch to get that to compile 
properly on 10.6, and those should have been forward ported to the 3.1 
branch.

Could you please do a checkout of the 3.1 branch and test if that solves 
the issue for you (it does for me)?

One issue you are running into is that the compiler on 10.6 generates 
64-bit code by default, while Python's build system assumes that the 
compiler generates 32-bit code. This was fixed in python 2.6.3 and the 
3.x branches a while back, but hasn't made it into a release of 3.1 yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7102>
_______________________________________

From report at bugs.python.org  Sun Oct 11 13:58:24 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Oct 2009 11:58:24 +0000
Subject: [issue7100] test_xmlrpc: global name 'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1255262304.52.0.129669505021.issue7100@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I can't repro on my windows box.
>From what I can see, for some reason the server thread isn't 
terminating, so we enter an errorhandling codepath that is broken.
The slew of errors that follow occur when the process is exiting and the 
worker threads have had the carpet pulled from underneath them, as it 
were.

We should remove the "stop_serving()" call, it is some rudiment of 
ancient code.  But the real error is still hidden, whatever caused the 
server to not exit.  If this is easily repro, maybe you can produce a 
traceback of the worker thread at this point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7100>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:03:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Oct 2009 12:03:12 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255262592.45.0.297366114203.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It was a bad idea to revert the change, because we may now forget about
the problem rather than fix it.

It is likely that the "dictionary changed size during iteration" occurs
because a GC collection gets triggered during the iteration on the
weakdict. A GC collection can destroy some objects in that case because
keeping an exception around (which the unittest change does) usually
creates reference cycles through the frame's locals.

It seems that WeakValueDictionary.items() isn't very robust in py3k ;)
We probably need to add list-returning variants, e.g. a listitems()
method (and, probably, listkeys() and listvalues() too)?

----------
nosy: +benjamin.peterson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:06:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Oct 2009 12:06:48 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255262808.64.0.3552806266.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

The unittest only keeps an exception _object_ around, not the associated 
traceback.  There should be no frames and thus reference cycles associated 
with this.
I agree that the problem should be tackled, rather than swept under the 
carpet like a revert does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:14:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Oct 2009 12:14:43 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1255262808.64.0.3552806266.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255263507.5914.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The unittest only keeps an exception _object_ around, not the associated 
> traceback.

In py3k, the traceback is attached to the exception (on the
__traceback__ attribute) ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:32:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Oct 2009 12:32:11 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255264331.66.0.779134141569.issue7060@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I disagree about reverting it. We have this bug report, and that change
is sitting on the merge queue again...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 15:09:36 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 11 Oct 2009 13:09:36 +0000
Subject: [issue7103] Error in config parser example (w/ Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>


New submission from Thomas Courbon <harthie at yahoo.fr>:

When ran in python 3.1.1 (hand compiled, fedora 11), the first example
of configparser module fail with :
Traceback (most recent call last):
  File "test1.py", line 22, in <module>
    config.write(configfile)
  File "/usr/local/lib/python3.1/configparser.py", line 394, in write
    fp.write("[%s]\n" % section)
TypeError: write() argument 1 must be bytes or buffer, not str

This can be solved by replacing :
with open('example.cfg', 'wb') as configfile:

by :
with open('example.cfg', 'w') as configfile:

Patch attached.

Cheer !
Thomas

----------
assignee: georg.brandl
components: Documentation
messages: 93858
nosy: georg.brandl, tcourbon
severity: normal
status: open
title: Error in config parser example (w/ Patch)
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________

From report at bugs.python.org  Sun Oct 11 15:13:15 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 11 Oct 2009 13:13:15 +0000
Subject: [issue7103] Error in config parser example (w/ Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255266795.43.0.0750009952129.issue7103@psf.upfronthosting.co.za>


Changes by Thomas Courbon <harthie at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15101/configparser_example_issue_7103.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:08:35 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Oct 2009 14:08:35 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255270115.19.0.388912771886.issue7060@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I didn't realize that the traceback was attached to the exception object 
in py3k.  This makes the use of such objects more dangerous because of the  
circular references.  The recommended practice of
exc_type, exc_obj = sys.exc_info()[:2]
is precisely to avoid any "accidents" with the tracebacks.
See also http://mail.python.org/pipermail/python-dev/2005-
August/055251.html
So, can one just clear the __traceback__ member?  That would make sense 
for the unittests, but it would make this manifestation of a GC bug go 
into hiding again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:45:06 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2009 15:45:06 +0000
Subject: [issue6027] test_xmlrpc_net fails when the ISP returns "302 Found"
In-Reply-To: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za>
Message-ID: <1255275906.61.0.470119146494.issue6027@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +krisvale, loewis
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6027>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:48:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2009 15:48:50 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255276130.87.0.58113031089.issue7092@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:51:03 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2009 15:51:03 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1255276263.13.0.843401692428.issue6896@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6896>
_______________________________________

From report at bugs.python.org  Sun Oct 11 18:01:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2009 16:01:52 +0000
Subject: [issue2100] unit test UnicodeWarning
In-Reply-To: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za>
Message-ID: <1255276912.59.0.202890898177.issue2100@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That try/except no longer exists on trunk. This issue can probably be
closed.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2100>
_______________________________________

From report at bugs.python.org  Sun Oct 11 18:09:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2009 16:09:45 +0000
Subject: [issue1729305] test_doctest fails when run in verbose mode
Message-ID: <1255277385.48.0.883877315242.issue1729305@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This test still fail on Win7 with Py2.6.3rc1 in verbose mode, it works
fine in normal mode.
I attached a file with the traceback.

----------
nosy: +ezio.melotti
versions: +Python 2.6 -Python 2.5
Added file: http://bugs.python.org/file15102/doctestfail.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729305>
_______________________________________

From report at bugs.python.org  Sun Oct 11 18:19:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2009 16:19:19 +0000
Subject: [issue7103] Error in config parser example (w/ Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255277959.08.0.905571138509.issue7103@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________

From report at bugs.python.org  Sun Oct 11 18:32:13 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 11 Oct 2009 16:32:13 +0000
Subject: [issue7104] test_descr uses __cmp__ which will never be called
In-Reply-To: <1255278733.49.0.73816773283.issue7104@psf.upfronthosting.co.za>
Message-ID: <1255278733.49.0.73816773283.issue7104@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The following is from Lib/test/test_descr.py.  It's trying to test if
looking up a special method on an object leaks references.  It tests it
by using __cmp__.  The test will always pass because Python 3 is trying
to look up __eq__, not __cmp__.  Hence, __cmp__ should be changed to __eq__.

        # Test lookup leaks [SF bug 572567]
        import sys,gc
        if hasattr(gc, 'get_objects'):
            class G(object):
                def __cmp__(self, other):
                    return 0
            g = G()
            orig_objects = len(gc.get_objects())
            for i in range(10):
                g==g
            new_objects = len(gc.get_objects())
            self.assertEqual(orig_objects, new_objects)

----------
components: Tests
messages: 93862
nosy: stutzbach
severity: normal
status: open
title: test_descr uses __cmp__ which will never be called
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7104>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:29:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Oct 2009 17:29:26 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

As mentioned in issue7060, weak dict iterators are easily broken by
cyclic garbage collection changing the size of the underlying dict storage:

  File "/home/rdmurray/python/py3k/Lib/weakref.py", line 121, in items
    for wr in self.data.values():
RuntimeError: dictionary changed size during iteration

One possible solution is to delay all removals until all iterators are
done. Here is a context manager-based solution.

----------
components: Library (Lib)
files: weakiter.patch
keywords: patch
messages: 93863
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: weak dict iterators are fragile because of unpredictable GC runs
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15103/weakiter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:29:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Oct 2009 17:29:50 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255282190.96.0.280107438393.issue7060@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +weak dict iterators are fragile because of unpredictable GC runs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:32:42 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 11 Oct 2009 17:32:42 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1255282362.96.0.142332319324.issue7060@psf.upfronthosting.co.za>


Changes by Jon Parise <jon at indelible.org>:


----------
nosy: +jon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:36:34 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 11 Oct 2009 17:36:34 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1255282594.63.0.497407112359.issue7105@psf.upfronthosting.co.za>


Changes by Jon Parise <jon at indelible.org>:


----------
nosy: +jon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:41:45 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Oct 2009 17:41:45 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1255282905.08.0.921265789387.issue4064@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

10.3 is a red herring, that is the deployment target and is as expected. 
If you install the current proper versions of Xcode for your 10.4 or later 
systems, things will work as designed.  Again, this is not the proper 
forum to discuss build problems.  If you still have problems, suggest 
asking questions in the pythonmac-sig mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:41:59 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Oct 2009 17:41:59 +0000
Subject: [issue4064] distutils.util.get_platform() is wrong for universal
	builds on macosx
In-Reply-To: <1223372506.67.0.0695437695796.issue4064@psf.upfronthosting.co.za>
Message-ID: <1255282919.36.0.449639053176.issue4064@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4064>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:57:28 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 11 Oct 2009 17:57:28 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1255283848.48.0.958861542006.issue7105@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> delay all removals until all iterators are done

+1

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________

From report at bugs.python.org  Sun Oct 11 20:04:30 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Sun, 11 Oct 2009 18:04:30 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal made
	from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1255284270.31.0.0642997948186.issue5377@psf.upfronthosting.co.za>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

PyPy is a bit of a special case, because it cares about the distinction
of int and long in the translation toolchain. Nevertheless, this
behavior has been annoying to us.

----------
nosy: +cfbolz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________

From report at bugs.python.org  Sun Oct 11 20:08:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Oct 2009 18:08:01 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal made
	from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1255284481.94.0.0163704558311.issue5377@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Carl, thanks for that.  I was just thinking about abandoning this issue 
as not worth fixing.

I need to look at Victor's patch again, but I recall that there were 
still some issues:  e.g., if the __int__ method of some class returns a 
bool, that still ends up getting returned as a bool rather than an int.  
Getting everything exactly right seemed fiddly enough to make it not 
worth the effort.

Would the bool/int distinction matter to PyPy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________

From report at bugs.python.org  Sun Oct 11 20:09:37 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 11 Oct 2009 18:09:37 +0000
Subject: [issue7085] strptime problem
In-Reply-To: <1255042131.92.0.134837798932.issue7085@psf.upfronthosting.co.za>
Message-ID: <1255284577.67.0.167048707066.issue7085@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The crash happens whenever you import code on a secondairy thread.

I consider this a platform bug in the implementation of dlopen, because 
the crash also occurs with this variant on test():

def test():
    print "DL"
    p = os.path.join(os.path.dirname(time.__file__), '_locale.so')
    m = dl.open(p)
    print m

(Don't forget to import dl and os before running the code).

I'm investigating a workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7085>
_______________________________________

From report at bugs.python.org  Sun Oct 11 20:13:10 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Sun, 11 Oct 2009 18:13:10 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal
	made	from -sys.maxint-1
In-Reply-To: <1255284481.94.0.0163704558311.issue5377@psf.upfronthosting.co.za>
Message-ID: <4AD2202F.6020609@gmx.de>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

[...]
> Would the bool/int distinction matter to PyPy?

No, it's really mostly about longs and ints, because RPython does not 
have automatic overflowing of ints to longs (the goal is really to 
translate ints them to C longs with normal C overflow behaviour). I 
would understand if you decide for wontfix, because you are not supposed 
to care about int/long and as I said, PyPy is a special case.

Thanks,

Carl Friedrich

----------
title: Strange behavior when performing int on a Decimal made from -sys.maxint-1 -> Strange behavior when performing int on a Decimal made	from -sys.maxint-1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________

From report at bugs.python.org  Sun Oct 11 20:29:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Oct 2009 18:29:14 +0000
Subject: [issue7104] test_descr uses __cmp__ which will never be called
In-Reply-To: <1255278733.49.0.73816773283.issue7104@psf.upfronthosting.co.za>
Message-ID: <1255285754.03.0.245873285242.issue7104@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for nitpicking! Fixed in r75362.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7104>
_______________________________________

From report at bugs.python.org  Sun Oct 11 21:24:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2009 19:24:10 +0000
Subject: [issue7103] Error in config parser example (w/ Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255289050.06.0.0344495783913.issue7103@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 6969, where it has been fixed.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
superseder:  -> configparser
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________

From report at bugs.python.org  Sun Oct 11 21:40:52 2009
From: report at bugs.python.org (Bruce vanNorman)
Date: Sun, 11 Oct 2009 19:40:52 +0000
Subject: [issue7106] Python crashed in the middle of an argument between wx
	and boa_constructor
In-Reply-To: <1255290052.69.0.436767775927.issue7106@psf.upfronthosting.co.za>
Message-ID: <1255290052.69.0.436767775927.issue7106@psf.upfronthosting.co.za>


New submission from Bruce vanNorman <brucevannorman at gmail.com>:

I don't know where this problem truly belongs, but Python did crash.
- I was trying to save my boa project when the event occurred.
- The software & versions are correctly identified in the "bugreport"

----------
components: Extension Modules
files: python-bugreport.txt
messages: 93872
nosy: bvn
severity: normal
status: open
title: Python crashed in the middle of an argument between wx and boa_constructor
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file15104/python-bugreport.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7106>
_______________________________________

From report at bugs.python.org  Sun Oct 11 21:59:59 2009
From: report at bugs.python.org (Grzegorz Adam Hankiewicz)
Date: Sun, 11 Oct 2009 19:59:59 +0000
Subject: [issue7107] Missing uninstallation instructions for mac
In-Reply-To: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
Message-ID: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>


New submission from Grzegorz Adam Hankiewicz <gradha at users.sourceforge.net>:

I've installed the official 2.6.3 dmg file of python and now want to 
uninstall it to revert to the python version included by default by the 
OS. I would do so if I knew what I have to remove or change.

----------
components: Installation
messages: 93873
nosy: gradha
severity: normal
status: open
title: Missing uninstallation instructions for mac
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7107>
_______________________________________

From report at bugs.python.org  Sun Oct 11 22:16:40 2009
From: report at bugs.python.org (Fredrik Hedman)
Date: Sun, 11 Oct 2009 20:16:40 +0000
Subject: [issue7102] Problems building pyhton from source on Snow Leopard (Mac
	OS X 10.6)
In-Reply-To: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>
Message-ID: <93025971790150902225317396940389800155-Webmail@me.com>


Fredrik Hedman <fredrik.hedman at me.com> added the comment:

Hi Ronald,

I checked out release31-maint from the python svn.  It compiles fine and passes all the tests.

So if I understand you correctly, these corrections need to be moved into 3.1.1 and that is also
tru for the 32/64-bit compilation issues. 

Cheers,
/Fredrik Hedman

On Sunday, October 11, 2009, at 01:36PM, "Ronald Oussoren" <report at bugs.python.org> wrote:
>
>Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
>Fredrik: OSX 10.6 was released after Python 3.1.1. I know that we had to 
>apply a number of patches to the 2.6 branch to get that to compile 
>properly on 10.6, and those should have been forward ported to the 3.1 
>branch.
>
>Could you please do a checkout of the 3.1 branch and test if that solves 
>the issue for you (it does for me)?
>
>One issue you are running into is that the compiler on 10.6 generates 
>64-bit code by default, while Python's build system assumes that the 
>compiler generates 32-bit code. This was fixed in python 2.6.3 and the 
>3.x branches a while back, but hasn't made it into a release of 3.1 yet.
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue7102>
>_______________________________________
>
>

----------
title: Problems building pyhton from source on Snow Leopard (Mac OS X 10.6) -> Problems building pyhton from source on Snow Leopard (Mac OS X  10.6)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7102>
_______________________________________

From report at bugs.python.org  Sun Oct 11 23:05:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Oct 2009 21:05:54 +0000
Subject: [issue7084] printing a list releases the GIL carelessly
In-Reply-To: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>
Message-ID: <1255295154.06.0.9431782608.issue7084@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! The patch has been committed in trunk in r75367. I am waiting
for the 2.6 branch to unfreeze before backporting it.

----------
assignee:  -> pitrou
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> pending
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7084>
_______________________________________

From report at bugs.python.org  Sun Oct 11 23:23:54 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Oct 2009 21:23:54 +0000
Subject: [issue7106] Python crashed in the middle of an argument between wx
	and boa_constructor
In-Reply-To: <1255290052.69.0.436767775927.issue7106@psf.upfronthosting.co.za>
Message-ID: <1255296234.67.0.287849937835.issue7106@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It's a Boa Constructor bug. And technically Python didn't crash, it threw 
an exception and that triggered Boa Constructor exit with a non-zero 
status.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7106>
_______________________________________

From report at bugs.python.org  Sun Oct 11 23:32:26 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 11 Oct 2009 21:32:26 +0000
Subject: [issue7103] Error in config parser example (w/ Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255296746.06.0.696001714481.issue7103@psf.upfronthosting.co.za>


Thomas Courbon <harthie at yahoo.fr> added the comment:

Due to its quite generic title I was unable to find this issue.
Sorry for the duplicate.

Thomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________

From report at bugs.python.org  Sun Oct 11 23:37:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2009 21:37:29 +0000
Subject: [issue7103] Error in config parser example (w/ Patch)
In-Reply-To: <1255266575.87.0.417277827864.issue7103@psf.upfronthosting.co.za>
Message-ID: <1255297049.25.0.54229988651.issue7103@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, no blame attaches to you, and thanks for the report.  (_I_ had
trouble finding the issue and I remembered that it existed.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7103>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:44:07 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sun, 11 Oct 2009 22:44:07 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1255301047.88.0.418884737394.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Re: msg 93821, the comment about redundant entries being appended to a 
menu when an EditorWindow is destroyed:

I've reproduced this behavior in Tk-Cocoa itself, and have concluded it's 
not an issue with IDLE (or my patches). I've filed bug 
https://sourceforge.net/tracker/?
func=detail&atid=112997&aid=2876709&group_id=12997 at SF to address this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:49:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2009 22:49:30 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255301370.41.0.744505179907.issue7058@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've refactored the code and added more checks (cwd, all three stdio
attributes).  Patch attached.  I'm not done with this because I want to
make the reporting more visible.

----------
Added file: http://bugs.python.org/file15105/refactored_environment_checking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Mon Oct 12 01:33:35 2009
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Oct 2009 23:33:35 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

I am testing this out of the trunk on OS X 10.5.7:

uclid:trunk minge$ uname -a
Darwin euclid.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31
22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
euclid:trunk minge$ ./python.exe Lib/test/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests) ... FAIL

======================================================================
FAIL: test_getstatus (__main__.CommandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_commands.py", line 60, in test_getstatus
    self.assertTrue(re.match(pat, getstatus("/."), re.VERBOSE))
AssertionError: None is not True

----------------------------------------------------------------------
Ran 2 tests in 0.047s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_commands.py", line 69, in <module>
    test_main()
  File "Lib/test/test_commands.py", line 64, in test_main
    run_unittest(CommandTests)
  File
"/Users/minge/Research/Languages/python/trunk/Lib/test/test_support.py",
line 884, in run_unittest
    _run_suite(suite)
  File
"/Users/minge/Research/Languages/python/trunk/Lib/test/test_support.py",
line 867, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_commands.py", line 60, in test_getstatus
    self.assertTrue(re.match(pat, getstatus("/."), re.VERBOSE))
AssertionError: None is not True

[30608 refs]
euclid:trunk minge$ patch -p0 < test_commands.patch 
patching file Lib/test/test_commands.py
euclid:trunk minge$ ./python.exe Lib/test/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.040s

OK
[30459 refs]

According to the OS X documentation for ls(1) [1] the output of ls can
include the '@' character to denote that file has "extended attributes".
 The attached patch adjust the regex which is applied to the output of
ls to account for this fact (a more rigorous approach would have
conditioned the '@' check on OS X, but I wasn't sure if it was worth the
added complexity).  

[1]
http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Reference/ManPages/man1/ls.1.html

----------
components: Tests
files: test_commands.patch
keywords: patch
messages: 93881
nosy: minge
severity: normal
status: open
title: test_commands.py failing on OS X 10.5.7 due to '@' in ls output
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15106/test_commands.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7108>
_______________________________________

From report at bugs.python.org  Mon Oct 12 01:44:23 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Oct 2009 23:44:23 +0000
Subject: [issue7107] Missing uninstallation instructions for mac
In-Reply-To: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
Message-ID: <1255304663.69.0.106252325735.issue7107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As far as I know, there is no documented way to totally install a 
python.org OS X installation and the OS X installer does not provide a 
general way to uninstall a package.  So it would be nice for the Python 
installer to provide some sort of uninstall script.

In the meantime, if you just want to temporarily revert, you can modify 
your .bash_profile or other login shell initialization to fix $PATH to 
not add "/Library/Frameworks/Python.framework/Versions/2.6/bin" to $PATH 
(you'll probably find this was added at the end of .bash_profile by the 
installer or by "Update Shell Profile.command") and/or to not have 
/usr/local/bin appear before /usr/bin on $PATH.

If you want to permanently remove the python.org installed version, 
paste the following lines up to and including the chmod into a posix-
compatible shell:

tmpfile=/tmp/generate_file_list
cat <<"NOEXPAND" > "${tmpfile}"
#!/bin/sh
version="${1:-"2.6"}"
file -h /usr/local/bin/* | grep \
"symbolic link to ../../../Library/Frameworks/Python.framework/"\
"Versions/${version}" | cut -d : -f 1
echo "/Library/Frameworks/Python.framework/Versions/${version}"
echo "/Applications/Python ${version}"
set -- Applications Documentation Framework ProfileChanges \
         SystemFixes UnixTools
for package do
  echo "/Library/Receipts/Python${package}-${version}.pkg"
done
NOEXPAND
chmod  ug+x ${tmpfile}

----

The shell script writes to its standard output a list of files and top-
level directories that should be removed.  You can examine the list by 
just running the script:

  ${tmpfile} 2.6

To actually delete the files:

  ${tmpfile} 2.6 | sed -e "s/^.*$/sudo rm -r \"&\"/g" | sh

You will still have to manually edit your .bash_profile script as above.  
Another minor loose end is that the script does not attempt to modify 
the frameworks "Versions/Current" symlink but I don't know of anything 
that depends on that.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7107>
_______________________________________

From report at bugs.python.org  Mon Oct 12 02:02:01 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Oct 2009 00:02:01 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1255305721.88.0.753709046077.issue3326@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I propose that we remove -fno-strict-aliasing for gcc >= 4.3.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Mon Oct 12 03:18:01 2009
From: report at bugs.python.org (Bonnie Douglas)
Date: Mon, 12 Oct 2009 01:18:01 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255310281.78.0.708766180509.issue6941@psf.upfronthosting.co.za>


Bonnie Douglas <bonnie.douglas at biarri.com> added the comment:

I too seem to have experienced this same problem.  I am running Windows
Vista.  After choosing to shut down my computer and restart without
cleanly shutting down IDLE I got a "socket error" - socket
error:connection refused when I next tried to launch IDLE.  After
pressing OK I got another message: "IDLE's subprocess didn't make a
connection. Either IDLE can't start a subprocess or personal firewall
software is blocking the connection" 

After a search through the web I simply ran the python-6.2.3.msi file
again and chose to "repair" Python 2.6.3 - this has solved the problem.
 Hope this helps.

----------
nosy: +bdouglasoz
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Mon Oct 12 03:26:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2009 01:26:13 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255310773.9.0.0830799318654.issue7058@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a finished version of the refactoring patch.  It introduces a
new category in the list of test statuses at in the summary to list the
tests that have changed the execution environment.  This patch makes it
easy to add additional things to check and restore, and I've added
'sys.path' checking.

----------
Added file: http://bugs.python.org/file15107/refactored_environment_checking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Mon Oct 12 03:30:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2009 01:30:26 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255311026.3.0.343132231939.issue7058@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file15105/refactored_environment_checking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:37:55 2009
From: report at bugs.python.org (Bruce vanNorman)
Date: Mon, 12 Oct 2009 02:37:55 +0000
Subject: [issue7106] Python crashed in the middle of an argument between
	wx	and boa_constructor
In-Reply-To: <1255296234.67.0.287849937835.issue7106@psf.upfronthosting.co.za>
Message-ID: <4AD2967C.6030803@gmail.com>


Bruce vanNorman <brucevannorman at gmail.com> added the comment:

Roger that, and thanks. I've just started learning Python this summer. 
Before I retired I spent 20 years supporting & maintaining a rather 
specialized programming language that was a component of something 
called EIS (Boeing - Estimating Information System).
---
Scrounging the web, I've found many seeming unrelated, but identical 
"line #425 of Help.py in boa package" nastygrams. So boa was suspect 
from the beginning.
---
I think I'll poke into it, so I too, can make Python appear to crash:-) 
Maybe I'll fix boa by accident? Thanks for the knowledge.
--- so much to learn, so little time - TTFN
Brett Cannon wrote:
> Brett Cannon <brett at python.org> added the comment:
> 
> It's a Boa Constructor bug. And technically Python didn't crash, it threw 
> an exception and that triggered Boa Constructor exit with a non-zero 
> status.
> 
> ----------
> nosy: +brett.cannon
> resolution:  -> invalid
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7106>
> _______________________________________
>

----------
title: Python crashed in the middle of an argument between wx and boa_constructor -> Python crashed in the middle of an argument between wx	and boa_constructor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7106>
_______________________________________

From report at bugs.python.org  Mon Oct 12 09:21:42 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Mon, 12 Oct 2009 07:21:42 +0000
Subject: [issue7109] broken link on news page
In-Reply-To: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>
Message-ID: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>


New submission from Matthias Kievernagel <mkiever at web.de>:

Hello,

there is a broken link on
  http://www.python.org/news/
at
Python 3.0 is an ex-release! Long live Python 3.1!
There will be no Python 3.0.2 release or further 3.0.x maintenance/
security releases. All users of Python 3.0 are strongly encouraged to 
upgrade to Python 3.1.

This link is dead (pointing at some fjord, it's an ex-link :):
  http://mail.python.org/pipermail/python-list/2009-July/718561.html 
Found this in the archives, guess this is the correct link:
  http://mail.python.org/pipermail/python-list/2009-July/187218.html

Hope this is the right place to report website issues.

Regards,
Matthias Kievernagel

----------
components: None
messages: 93887
nosy: mkiever
severity: normal
status: open
title: broken link on news page

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7109>
_______________________________________

From report at bugs.python.org  Mon Oct 12 10:02:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Oct 2009 08:02:56 +0000
Subject: [issue7099] Decimal.is_normal should return True even for numbers
	with exponent > Emax
In-Reply-To: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>
Message-ID: <1255334576.11.0.669833834772.issue7099@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Note to self:  when fixing this, make sure that Decimal.number_class is
also behaving sensibly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7099>
_______________________________________

From report at bugs.python.org  Mon Oct 12 10:08:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Oct 2009 08:08:54 +0000
Subject: [issue7110] Output test failures on stderr in regrtest.py
In-Reply-To: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
Message-ID: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

regrtest.py should output all the names of the tests that fail and their
tracebacks on stderr.
This will provide an easy way to filter out the relevant information
(errors and tracebacks) from all the other outputs.

The current behavior seems incoherent, some tracebacks are sent to
stdout and other to stderr (see attached log).

----------
components: Tests
files: stdout_stderr.txt
messages: 93889
nosy: ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Output test failures on stderr in regrtest.py
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15108/stdout_stderr.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7110>
_______________________________________

From report at bugs.python.org  Mon Oct 12 10:22:57 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Oct 2009 08:22:57 +0000
Subject: [issue7109] broken link on news page
In-Reply-To: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>
Message-ID: <20091012082245.GC10519@ubuntu.ubuntu-domain>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

> Hope this is the right place to report website issues.

Not actually, 
http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets

to report a bug or to suggest an enhancement for the python.org
website, please send an e-mail message to 
<webmaster at python dot org>.

If you're reporting a problem (a broken link, typo, formatting
glitch), please include the URL of the affected page.

Closing this.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7109>
_______________________________________

From report at bugs.python.org  Mon Oct 12 10:23:17 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Oct 2009 08:23:17 +0000
Subject: [issue7109] broken link on news page
In-Reply-To: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>
Message-ID: <1255335797.83.0.0242593262159.issue7109@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7109>
_______________________________________

From report at bugs.python.org  Mon Oct 12 10:23:20 2009
From: report at bugs.python.org (Peter Eisentraut)
Date: Mon, 12 Oct 2009 08:23:20 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>


New submission from Peter Eisentraut <peter_e at gmx.net>:

bash$ python3.1 -c 'pass' 2>&-
Aborted (core dumped)

(I verified, the core dump belongs to python.)

If you remove the redirection thingy at the end, it works.

Not sure why I ever wrote that code, but it has been working since
forever up to python3.0.

----------
components: Interpreter Core
messages: 93891
nosy: petere
severity: normal
status: open
title: core dump when stderr is moved
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Mon Oct 12 11:01:08 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Mon, 12 Oct 2009 09:01:08 +0000
Subject: [issue7109] broken link on news page
In-Reply-To: <1255332102.92.0.0966225576747.issue7109@psf.upfronthosting.co.za>
Message-ID: <1255338068.61.0.0510465477621.issue7109@psf.upfronthosting.co.za>


Matthias Kievernagel <mkiever at web.de> added the comment:

Sorry. Somehow this page did not show up on my google search on 
python.org. Problem sent to webmaster.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7109>
_______________________________________

From report at bugs.python.org  Mon Oct 12 11:56:37 2009
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 12 Oct 2009 09:56:37 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255341397.63.0.0550094323836.issue7111@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Mon Oct 12 13:56:49 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 12 Oct 2009 11:56:49 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too large
	for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I've got this warning while compiling on coLinux.

gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I.
-IInclude
 -I./Include   -DPy_BUILD_CORE -o Objects/unicodectype.o
Objects/unicodectype.c
In file included from Objects/unicodectype.c:34:
Objects/unicodetype_db.h: In function '_PyUnicodeUCS2_ToNumeric':
Objects/unicodetype_db.h:2077: warning: integer constant is too large
for 'long'
 type

This issue is related to issue1571184, I think.

----------
messages: 93893
nosy: ocean-city
severity: normal
status: open
title: unicodetype_db.h warning: integer constant is too large for 'long'
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:10:34 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Oct 2009 12:10:34 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too
	large	for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <4AD31CB7.6010408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Hirokazu Yamamoto wrote:
> This issue is related to issue1571184, I think.

Assuming that you're using the SVN version of Python, I agree,
that's likely.

This is the line in question:

    case 0x5146:
        return (double) 1000000000000;

Looks like the code generator should append a ".0" to signal
that the value is indeed a double. It be even more readable,
if it'd use the scientific E-notation, ie. 1e12.

----------
nosy: +lemburg
title: unicodetype_db.h warning: integer constant is too large for 'long' -> unicodetype_db.h warning: integer constant is too large	for 'long'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:10:50 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Oct 2009 12:10:50 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too
	large	for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <1255349450.98.0.0591669573331.issue7112@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:43:05 2009
From: report at bugs.python.org (albert hofkamp)
Date: Mon, 12 Oct 2009 12:43:05 +0000
Subject: [issue7113] ConfigParser load speedup
In-Reply-To: <1255351384.96.0.56907836791.issue7113@psf.upfronthosting.co.za>
Message-ID: <1255351384.96.0.56907836791.issue7113@psf.upfronthosting.co.za>


New submission from albert hofkamp <a.t.hofkamp at tue.nl>:

Current implementation (r71564) uses "'%s\n%s' % (old_val, new_line)" to
merge multi-line options into one string.
For options with many lines, this wastes a lot of CPU power.

Attached patch against r71564 fixes this problem by first building a
list of lines for each loaded option, and after reading the whole file,
merging them with the already loaded data. In that way, the '\n'.join()
can be performed once.
Patched ConfigParser.py works against test/test_cfgparser.py (and Python
2.5)

We have witnessed a reduction from 4 hours to 3 seconds loading time
with Python 2.6 and an option of 800000 lines.

----------
components: Library (Lib)
files: speedfix_71564.patch
keywords: patch
messages: 93895
nosy: aioryi
severity: normal
status: open
title: ConfigParser load speedup
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file15109/speedfix_71564.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7113>
_______________________________________

From report at bugs.python.org  Mon Oct 12 15:03:17 2009
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 12 Oct 2009 13:03:17 +0000
Subject: [issue5911] built-in compile() should take encoding option.
In-Reply-To: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>
Message-ID: <1255352597.0.0.296435699751.issue5911@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5911>
_______________________________________

From report at bugs.python.org  Mon Oct 12 15:54:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Oct 2009 13:54:38 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255355678.11.0.16781707454.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm able to reproduce this on Debian Lenny/x86_64 with a home-built gcc
4.4.0 and the --with-computed-gotos and --with-tsc configure options.

I'm compiling with:

CC=gcc-4.4 ./configure --with-tsc --with-computed-gotos && make

The Python executable builds successfully, and then the module build
stage fails exactly as Artur described.  Here's a minimal failing example:

Python 3.2a0 (py3k:75376, Oct 12 2009, 14:32:36)
[GCC 4.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(*args): return None
...
>>> def g(*args): return f(*args)
...
>>> g()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in g
TypeError: f() argument after ** must be a mapping, not tuple

With gcc 4.3.2 I get no failure.  With either of the configure options
removed I get no failure.

After some investigation, I believe the problem is in Python/ceval.c: 
what's going on is that the inline x86 assembly for the READ_TIMESTAMP
macro is clobbering the rdx register.  This clobbering changes the value
of the 'flags' variable in _call_function_var_kw, leading the
ext_do_call to think that it's supposed to be doing a
CALL_FUNCTION_VAR_KW instead of a CALL_FUNCTION_VAR.

I believe this *is* a Python bug:  the inline assembly should be fixed
to use the eax and edx registers explicitly instead of using the "=A"
constraint;  for x86_64, "=A" apparently means the 64-bit rax register,
rather than the edx/eax pair of 32-bit registers (though it's difficult
to find any mention of this in the gcc documentation).

I don't know why the --with-computed-gotos configure option affects this.

----------
assignee:  -> mark.dickinson
keywords: +easy
nosy: +mark.dickinson
priority:  -> critical
stage:  -> needs patch
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Mon Oct 12 16:55:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Oct 2009 14:55:25 +0000
Subject: [issue5911] built-in compile() should take encoding option.
In-Reply-To: <1241315725.1.0.346952935822.issue5911@psf.upfronthosting.co.za>
Message-ID: <1255359325.14.0.418138533155.issue5911@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch as it currently stands is unacceptable because it changes
public APIs.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5911>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:14:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Oct 2009 18:14:04 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255371244.09.0.495849076987.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

Martin, would you be able to take a look at this?

N.B.  I also tried './configure --with-tsc && make && make test' for a 
build of the trunk on OS X 10.6;  the configure and make steps succeeded, 
but 'make test' immediately segfaults;  gdb shows the segfault coming from 
ceval.c.  This patch fixes that segfault.

----------
keywords: +patch
nosy: +loewis
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15110/tsc_x86_64.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:16:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Oct 2009 18:16:57 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255371417.17.0.784773347111.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

N.B.  The patch assumes that unsigned int has 32 bits.  This is almost 
certainly true on the platforms of interest, but it might be better to use  
uint64_t and uint32_t throughout the tsc code.  For Python 2.7 and 3.x, 
uint32_t and uint64_t are already detected by the configure script;  for 
2.6, the detection might need to be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:45:18 2009
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 12 Oct 2009 18:45:18 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255373118.53.0.734074773107.issue7064@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

This change shows a regression (https://bugs.launchpad.net/bugs/449734),
the setup.py file might not be correct, but it did work before this
change (with plain distutils). Quoting from the report:


Set setup.py file looks like this:
setup(name='update-manager',
...
      ext_modules=[Extension('UpdateManager/fdsend',
                             ['UpdateManager/fdsend/fdsend.c'])],
...

WIth 2.6.4~rc1 the logs read:
copying build/lib.linux-x86_64-2.6/fdsend.so ->
/tmp/buildd/update-manager-0.126.1/debian/tmp/usr/lib/python2.6/dist-packages

With 2.6.3:
copying build/lib.linux-x86_64-2.6/UpdateManager/fdsend.so ->
/home/egon/devel/update-manager/checkout/build-area/update-manager-0.126.1/debian/tmp/usr/lib/python2.6/dist-packages/UpdateManager

So it looks like python is eating a prefix.

http://bugs.python.org/issue7064

is why this change was made.

Reading that, it was done because setuptools assumes that the method
is always called with the full dotted name, when it was just being called
with the last part of it.

However, update-manager isn't using a dotted module path anyway, it's
passing a path.

http://docs.python.org/distutils/setupscript.html#extension-names-and-packages

shows that you would be expected to use

      ext_modules=[Extension('UpdateManager.fdsend',
                             ['UpdateManager/fdsend/fdsend.c'])],

(note . not / in the first line)

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Mon Oct 12 21:01:05 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Oct 2009 19:01:05 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255374065.8.0.182989040379.issue7064@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Tarek,

Can you please look at this for 2.6.4?  We might need another rc and it
would be better to do that sooner rather than later.

Thanks!

----------
priority:  -> release blocker
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Mon Oct 12 21:16:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Oct 2009 19:16:22 +0000
Subject: [issue6970] Redundant calls made to comparison methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1255374982.86.0.914410643603.issue6970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Assigning to myself so this doesn't get forgotten.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________

From report at bugs.python.org  Mon Oct 12 22:00:52 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Oct 2009 20:00:52 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255377652.34.0.83767803744.issue7064@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Looking at it now

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Mon Oct 12 22:30:30 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Mon, 12 Oct 2009 20:30:30 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255379430.87.0.315854359022.issue7064@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

FYI, a fix allowing setuptools to work with 2.6.3 is now checked in, and
will be released soon (preferably in a few days, unless new bugs turn
up).  If you are experiencing issues with this and would like to try the
fixed version(s), please see the announcement here:

http://mail.python.org/pipermail/distutils-sig/2009-October/013822.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Mon Oct 12 23:32:53 2009
From: report at bugs.python.org (Greg Baker)
Date: Mon, 12 Oct 2009 21:32:53 +0000
Subject: [issue7114] HTMLParser doesn't handle <![CDATA[ ... ]]>
In-Reply-To: <1255383173.02.0.819385756545.issue7114@psf.upfronthosting.co.za>
Message-ID: <1255383173.02.0.819385756545.issue7114@psf.upfronthosting.co.za>


New submission from Greg Baker <ggbaker at sfu.ca>:

I believe what I'm seeing here is somewhat related to issue 670664, but
is easier to handle because of the CDATA structure.  Basically,
HTMLParser doesn't recognize CDATA sections at all, so their content is
incorrectly parsed like normal data.

The following is an attempt to parse (a snippet of) valid XHTML, but it
raises an HTMLParseError.

data = """<script type="text/javascript">
//<![CDATA[
function foo() {
document.write('"></' + 'script>');}
//]]>
</script>"""

from HTMLParser import HTMLParser
parser = HTMLParser()
parser.feed(data)

----------
components: Library (Lib)
messages: 93905
nosy: ggbaker
severity: normal
status: open
title: HTMLParser doesn't handle <![CDATA[ ... ]]>
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7114>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:24:03 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Oct 2009 22:24:03 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1255386243.56.0.505772662943.issue4120@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Looking at the description of manifest files, it appears that just
removing the assemblyIdentity-element results in an invalid manifest file:

http://msdn.microsoft.com/en-us/library/aa374219(VS.85).aspx

It appears that the entire dependency-element referencing the MS VC90
CRT DLL has to be removed in order to make the manifest correct again.

Looking at the schema, it's enough to just remove the
dependentAssembly-element:

http://msdn.microsoft.com/en-us/library/aa375635(VS.85).aspx

Reading up on the manifest trouble-shooting page at (near the end of the
page):

http://msdn.microsoft.com/en-us/library/ms235342.aspx

it may actually be enough to just place the Microsoft.VC90.CRT.manifest
file into the Python folder (the one with python.exe and the CRT DLLs):

"""
If the operating system fails to find the CRT or any other assembly as a
shared assembly, it starts looking for the assembly as a private
assembly. It searches for private assemblies in the following order:

   1. Check the application local folder for a manifest file with name
<assemblyName>.manifest. In this example, the loader tries to find
Microsoft.VC90.CRT.manifest in the same folder as appl.exe. If the
manifest is found, the loader loads the CRT DLL from the application
folder. If the CRT DLL is not found, load fails.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:29:53 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Oct 2009 22:29:53 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255386593.86.0.18276723163.issue7064@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am opening another issue to keep a record of the particular case
Matthias brought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:33:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Oct 2009 22:33:04 +0000
Subject: [issue7115] extension module builds fail when using paths in the
	extension name
In-Reply-To: <1255386784.29.0.0870710106996.issue7115@psf.upfronthosting.co.za>
Message-ID: <1255386784.29.0.0870710106996.issue7115@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This change shows a regression (https://bugs.launchpad.net/bugs/449734),
the setup.py file might not be correct, but it did work before this
change (with plain distutils). Quoting from the report:


Set setup.py file looks like this:
setup(name='update-manager',
...
      ext_modules=[Extension('UpdateManager/fdsend',
                             ['UpdateManager/fdsend/fdsend.c'])],
...

With 2.6.4~rc1 the logs read:
copying build/lib.linux-x86_64-2.6/fdsend.so ->
/tmp/buildd/update-manager-0.126.1/debian/tmp/usr/lib/python2.6/dist-packages

With 2.6.3:
copying build/lib.linux-x86_64-2.6/UpdateManager/fdsend.so ->
/home/egon/devel/update-manager/checkout/build-area/update-manager-0.126.1/debian/tmp/usr/lib/python2.6/dist-packages/UpdateManager

So it looks like python is eating a prefix.

http://bugs.python.org/issue7064

is why this change was made.

Reading that, it was done because setuptools assumes that the method
is always called with the full dotted name, when it was just being called
with the last part of it.

However, update-manager isn't using a dotted module path anyway, it's
passing a path.

http://docs.python.org/distutils/setupscript.html#extension-names-and-packages

shows that you would be expected to use

      ext_modules=[Extension('UpdateManager.fdsend',
                             ['UpdateManager/fdsend/fdsend.c'])],

(note . not / in the first line)

----------
assignee: tarek
components: Distutils
messages: 93908
nosy: barry, doko, tarek
priority: release blocker
severity: normal
status: open
title: extension module builds fail when using paths in the extension name
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7115>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:37:41 2009
From: report at bugs.python.org (Jess Austin)
Date: Mon, 12 Oct 2009 22:37:41 +0000
Subject: [issue7116] str.join() should be documented as taking an iterable
In-Reply-To: <1255387061.17.0.69385266786.issue7116@psf.upfronthosting.co.za>
Message-ID: <1255387061.17.0.69385266786.issue7116@psf.upfronthosting.co.za>


New submission from Jess Austin <jess.austin at gmail.com>:

In its __doc__ string and in the documentation, str.join() is described
as taking a sequence.  This is not general enough; it actually takes any
iterable of strings:

    >>> ','.join(str(x) for x in range(5))
    '0,1,2,3,4'

Maybe this is a small nit to pick, but it slowed me down for a few
minutes, and I already vaguely remembered that str.join() could handle
iterables.

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 93909
nosy: georg.brandl, jess.austin
severity: normal
status: open
title: str.join() should be documented as taking an iterable
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7116>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:41:03 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Oct 2009 22:41:03 +0000
Subject: [issue7115] extension module builds fail when using paths in the
	extension name
In-Reply-To: <1255386784.29.0.0870710106996.issue7115@psf.upfronthosting.co.za>
Message-ID: <1255387263.86.0.352501589137.issue7115@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r75390.

Matthias could you check on your side with the UpdateManager
distribution that it working fine now in your environment ?

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7115>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:48:54 2009
From: report at bugs.python.org (Jess Austin)
Date: Mon, 12 Oct 2009 22:48:54 +0000
Subject: [issue7116] str.join() should be documented as taking an iterable
In-Reply-To: <1255387061.17.0.69385266786.issue7116@psf.upfronthosting.co.za>
Message-ID: <1255387734.96.0.942131929291.issue7116@psf.upfronthosting.co.za>


Changes by Jess Austin <jess.austin at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15111/jointakesiterables.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7116>
_______________________________________

From report at bugs.python.org  Tue Oct 13 01:36:02 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 12 Oct 2009 23:36:02 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255390562.31.0.222063875095.issue7064@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Tarek - could you give the new issue link?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Tue Oct 13 01:51:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Oct 2009 23:51:02 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1255391462.26.0.335273926983.issue7105@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This new patch makes it possible to mutate the dict without messing with
the delayed removal when an iterator exists.

----------
Added file: http://bugs.python.org/file15112/weakiter2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________

From report at bugs.python.org  Tue Oct 13 02:51:27 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 13 Oct 2009 00:51:27 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1255395087.46.0.937475329385.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

This patch also removes empty dependentAssembly elements after removing
the VC.CRT assemblyIdentity element.

It seems not enough to just place the Microsoft.VC90.CRT.manifest and VC
runtime DLL files into the Python folder. On a system without the VC
runtime installed in winsxs, trying to import a pyd module build without
the patch fails with "ImportError: DLL load failed: ...". Import works
when 1) the manifest and VC runtime DLLs are also placed in the same
folder as the pyd file, or 2) the Microsoft Visual C++ 2008
redistributable package is installed, or 3) the pyd file is build with
the patch installed. Tested with Windows XP SP3, Python 2.6.3,
matplotlib 0.99.1, Visual Studio 2008 SP1.

----------
Added file: http://bugs.python.org/file15113/msvc9compiler_stripruntimes_regexp2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Tue Oct 13 03:33:41 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 13 Oct 2009 01:33:41 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1255397621.25.0.444608696392.issue1068268@psf.upfronthosting.co.za>


Changes by Reid Kleckner <rnk at mit.edu>:


----------
nosy: +rnk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Tue Oct 13 03:55:10 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Oct 2009 01:55:10 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too
	large	for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <1255398910.8.0.132913283602.issue7112@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Tue Oct 13 03:57:03 2009
From: report at bugs.python.org (Stuart Axon)
Date: Tue, 13 Oct 2009 01:57:03 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1255399023.66.0.729567056608.issue4972@psf.upfronthosting.co.za>


Stuart Axon <stu.axon at gmail.com> added the comment:

zipfile also would make a good target for a contextmanager (as noted here -
http://tarekziade.wordpress.com/2009/01/20/python-standard-lib-give-me-more-withs/
)

----------
nosy: +stuaxo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Tue Oct 13 04:04:19 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Oct 2009 02:04:19 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1255399459.13.0.224759090102.issue4972@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There's a patch for zipfile in #5511.

----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Tue Oct 13 05:22:43 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 13 Oct 2009 03:22:43 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1255404163.78.0.31173220944.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Can someone review this patch?  I believe it's sufficient for inclusion
now, as it includes docs and unit tests, but if anything about it
requires further attention I'd be happy to listen to change requests. 
We'd like get this into mainline where everyone can benefit rather than
continuing to maintain it out-of-tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Oct 13 05:27:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Oct 2009 03:27:51 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255404471.25.0.643797630223.issue7111@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The problem is the check_fd in _fileio.c checks fstat of 2, which
returns EBADFD. I'm not sure what about this redirection makes it a bad
file descriptor, though..

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Tue Oct 13 10:30:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 08:30:27 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

See the thread starting at:

http://mail.python.org/pipermail/python-dev/2009-October/092958.html

Eric suggested that we don't need a separate branch for this; sounds
fine to me.  It should still be possible to do the backport in stages,
though.  Something like the following?

(1) Check in David Gay's code plus necessary build changes,
configuration steps, etc;  conversions still use the old code.

(2) Switch to using the new code for float -> string (str, repr, float
formatting) and string -> float conversions (float, complex
constructors, numeric literals in Python code).  [Substeps?]

(3) Fix up builtin round function to use the new code.

(4) Make any necessary fixes to the documentation.  (Raymond, I assume
you'll take care of the whatsnew changes when the time comes?)

(1), (3) and (4) should be straightforward.  (2) is where most of the
work is, I think.  I think it should be possible to do the stage (2)
work in pieces without breaking too much.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 93918
nosy: eric.smith, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Backport py3k float repr to trunk
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Oct 13 14:31:55 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 13 Oct 2009 12:31:55 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255437115.32.0.239517455505.issue7111@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

After some searching around with Google, "2>&-" means "close file
descriptor 2" (i.e., standard error).

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Tue Oct 13 15:43:49 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 13 Oct 2009 13:43:49 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1255441429.16.0.228553473426.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I plan on reviewing the patch once my work with PyCon is completed, which 
should be within the next few weeks. The next release this would show up 
in (2.7/3.2) is not for some time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:17:34 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 13 Oct 2009 14:17:34 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1255443454.52.0.36751104028.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Okay, thanks, Jesse.  Didn't realize the Con was on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:19:48 2009
From: report at bugs.python.org (Gerald Thaler)
Date: Tue, 13 Oct 2009 14:19:48 +0000
Subject: [issue7118] urllib2.urlopen() timeout argument ignored after redirect
In-Reply-To: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>
Message-ID: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>


New submission from Gerald Thaler <gerald at netestate.de>:

When a HTTP request done with urllib2.urlopen() gets redirected, the 
second request will ignore the given timeout value and may hang 
indefinitely.

----------
messages: 93922
nosy: gthaler
severity: normal
status: open
title: urllib2.urlopen() timeout argument ignored after redirect
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7118>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:24:18 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 13 Oct 2009 14:24:18 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1255443858.5.0.332071271814.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Well, it's in feb, but I'm involved in some intense planning right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:30:01 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 13 Oct 2009 14:30:01 +0000
Subject: [issue7101] tarfile: OSError with TarFile.add(...,
	recursive=True) about non-existing file
In-Reply-To: <1255218562.66.0.694569702907.issue7101@psf.upfronthosting.co.za>
Message-ID: <1255444201.12.0.74822004102.issue7101@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7101>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:24:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 13 Oct 2009 15:24:26 +0000
Subject: [issue5915] PEP 383 implementation
In-Reply-To: <1241383095.9.0.96797527229.issue5915@psf.upfronthosting.co.za>
Message-ID: <1255447466.99.0.654330674318.issue5915@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm skeptical that a backport is a useful thing. First, the handler is 
primarily meant for use with PEP 383, which means that it's all 
internal; few applications will ever need to use it explicitly.

Furthermore, applications/libraries that do use it most likely will have 
to support 2.6 and earlier, as well, so they aren't helped with the 
handler. My advise to such libraries is that they should include and 
register their own implementation of it, or else fall back to "strict" 
on 2.x (say).

In any case: this issue is closed by PEP 383 being implemented. If you 
still desire a backport, please create a new report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5915>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:39:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 13 Oct 2009 15:39:58 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255448398.67.0.27158346078.issue7064@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The new issue is : #7115

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:40:26 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 13 Oct 2009 15:40:26 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255448426.13.0.497199601551.issue7064@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:49:49 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 13 Oct 2009 15:49:49 +0000
Subject: [issue7118] urllib2.urlopen() timeout argument ignored after redirect
In-Reply-To: <1255443588.46.0.439555512733.issue7118@psf.upfronthosting.co.za>
Message-ID: <1255448989.5.0.379203074474.issue7118@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Can you mention the python --version in which you encountered this issue?
And piece of code which loops indefinitely? 

The propagation of timeout to redirects has been fixed with Issue5102.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7118>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:07:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 13 Oct 2009 16:07:03 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255450023.76.0.922915981192.issue6603@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm skeptical that the patch is right (or, rather, that it is not a 
compiler bug). According to 

http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/i386.h?view=markup

in macro REG_CLASS_CONTENTS, the class AD_REGS includes indeed EDX and 
EAX. The exact place where this gets used has varied recently quite a 
lot; it currently lives in predicates.md:

http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/constraints.md?
revision=149373&view=markup

where "A" becomes the letter denoting the AD_REGS constraint. So IIUC, 
this means that EDX is the output of the insn, and your change should 
have no effect. I suggest talking to gcc people what the problem might 
be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:28:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 16:28:22 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255451302.63.0.753422311665.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a relevant gcc bug report:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249

As I understand it, the rules are that in 32-bit mode "A" means edx/eax 
for a 64-bit quantity, and in 64-bit mode "A" means rdx/rax for a 128-bit 
quantity and "rdx or rax" for a 64-bit quantity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:41:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 16:41:25 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255452085.35.0.444331579389.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I just found a more recent one:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41133

Whether this is a gcc misfeature or not, it sounds as though it's not 
going to change.

Maybe there should be two separate READ_TIMESTAMP cases?  One for x86 (or 
x86_64 in 32-bit mode), and one for x86_64 in 64-bit mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:42:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 13 Oct 2009 16:42:50 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255452170.66.0.882073241841.issue6603@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looking at this further, it seems that the rdtsc code got miscompiled on 
x64 for some time already. Consider this code

typedef unsigned long long uint64;
uint64 f(uint64 b)
{
   uint64 a;
   __asm__ __volatile__("rdtsc" : "=A" (a));
   return a+b;
}

My Apple gcc 4.0.1 compiles that into 

_f:
        pushq   %rbp
        movq    %rsp, %rbp
        rdtsc
        addq    %rdi, %rax
        leave
        ret

Here, %rdi is the incoming parameter; %rdx is not considered at all. 
This seems to come from DImode (double integer) processing: gcc just 
"knows" that a DImode variable lives in a single register on AMD64.

So even if your code is right in principle, I still think there is a gcc 
bug here.

As for the specific code: I'm not sure whether it's guaranteed that you 
can truncate output registers in an asm. If you can't, you should make 
the output registers 64-bit integers on AMD64. If you can, I think you 
can "simplify" the code by directly outputting to (int*)v and 
((int*)v)[1]; this would be worthwhile only if the generated code 
actually gets better by omitting the shift operation.

FWIW, I don't consider a bug that only occurs --with-tsc and only on 
AMD64 critical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:53:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 16:53:37 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255452817.03.0.651408081082.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As for the specific code: I'm not sure whether it's guaranteed that
> you  can truncate output registers in an asm. If you can't, you
> should make the output registers 64-bit integers on AMD64.

Specifying "eax" and "edx" directly, rather than using "a" and "d", 
would presumably also work here?


> If you can, I think you 
> can "simplify" the code by directly outputting to (int*)v and 
>((int*)v)[1];

I'll take a look at that.  Thanks.

> FWIW, I don't consider a bug that only occurs --with-tsc and only on 
> AMD64 critical.

Sorry.  I got overexcited.  Changed priority to 'normal'.

----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 19:02:48 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 13 Oct 2009 17:02:48 +0000
Subject: [issue7043] test_urllib: constructLocalFileUrl returns invalid URLs
	on Windows
In-Reply-To: <1254529761.1.0.362605990339.issue7043@psf.upfronthosting.co.za>
Message-ID: <1255453368.76.0.251900983607.issue7043@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Windows buildbots pass for this test. Closing the issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7043>
_______________________________________

From report at bugs.python.org  Tue Oct 13 19:17:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 17:17:11 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255454231.71.0.0140698567484.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

FWIW, the Linux source splits things up into 32-bit and 64-bit, and uses 
"A" for 32-bit and "a" and "d" for 64-bit;  their 64-bit code (after 
unwinding the macros) is essentially identical to the code in the patch.
See

http://lxr.linux.no/linux+v2.6.31/arch/x86/include/asm/msr.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 19:25:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Oct 2009 17:25:00 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1255454700.2.0.207054728736.issue7105@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It occurs weaksets have the same problem, here is a new patch fixing
them as well.

----------
Added file: http://bugs.python.org/file15114/weakiter3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:58:06 2009
From: report at bugs.python.org (Jon Nelson)
Date: Tue, 13 Oct 2009 18:58:06 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>


New submission from Jon Nelson <jnelson at users.sourceforge.net>:

import os
try:
  from email.mime.multipart import MIMEMultipart
except ImportError:
  from email.MIMEMultipart import MIMEMultipart

m = MIMEMultipart('form-data')

print m.items()
m.as_string()
print m.items()


print out:

[('Content-Type', 'multipart/form-data'), ('MIME-Version', '1.0')]
[('Content-Type', 'multipart/form-data;
boundary="===============0836597002796039051=="'), ('MIME-Version', '1.0')]

The latter is correct, the former is not - it is missing the boundary!
items() should behave the same regardless of whether or not as_string()
has been called.


Confirmed in 2.4 and 2.6

----------
components: Library (Lib)
messages: 93935
nosy: jnelson
severity: normal
status: open
title: email:  msg.items() returns different values before and after msg.as_string()
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________

From report at bugs.python.org  Tue Oct 13 21:57:03 2009
From: report at bugs.python.org (Jeff Senn)
Date: Tue, 13 Oct 2009 19:57:03 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>
Message-ID: <1255463823.3.0.0027328988228.issue4610@psf.upfronthosting.co.za>


Jeff Senn <senn at users.sourceforge.net> added the comment:

Has there been any action on this? a PEP?

I disagree that using ICU is good way to simply get proper
unicode casing. (A heavy hammer for a small task...)

I agree locales are a different issue (and would prefer
optional arguments to the unicode object casing methods -- 
that could then be used within any future sort of locale object 
to handle correct casing -- but don't rely on such.)

Most of the special casing rules can be accomplished by 
a decomposition (or recursive decomposition) on the character
followed by casing the result -- so NO new table is necessary
-- only marking up the characters so implicated (there are
extra unused bits in the char type table that could be used 
for this purpose -- so no additional space needed there either).  

What remains are a tiny handful of cases that need to be handled
in code.

I have a half finished implementation of this, in case anyone
is interested.

----------
nosy: +senn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:07:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 20:07:37 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255464457.01.0.206426475797.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> "simplify" the code by directly outputting to (int*)v and 
> ((int*)v)[1];

This does indeed seem to produce better compiler output, at least under 
Apple gcc-4.0.1, Apple gcc-4.2.1, and non-Apple gcc-4.4.1.

Here's a revised patch, which also separates the i386 and x86_64 cases.

Assigning to Martin for review.

----------
assignee: mark.dickinson -> loewis
Added file: http://bugs.python.org/file15115/tsc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:08:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 20:08:55 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255464535.49.0.422356894752.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops. Wrong patch.  Here's the right one.

----------
Added file: http://bugs.python.org/file15116/tsc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:09:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 20:09:00 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255464540.55.0.974100317675.issue6603@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file15115/tsc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:31:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Oct 2009 20:31:16 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255465876.34.0.339005122251.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Aargh.  I somehow deleted a backslash between testing and submitting that 
patch.  Sorry.

Third time lucky.

----------
Added file: http://bugs.python.org/file15117/tsc3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:48:04 2009
From: report at bugs.python.org (adgprogramming)
Date: Tue, 13 Oct 2009 20:48:04 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255466884.28.0.411850862479.issue6941@psf.upfronthosting.co.za>


adgprogramming <knd_adam at yahoo.com> added the comment:

Here is what happened to me. See the attachment.

P.S.: I launched the installer and hit repair. Everything went fine in 
the installer, but the problem still occured. 

Should I upgrade to 3.11?
If I have to make a change in the source code for IDLE, I am fine with 
that, I am an experienced programmer. I just need instructions.

Please help!

----------
nosy: +adgprogramming
Added file: http://bugs.python.org/file15118/idleerror.bmp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:50:37 2009
From: report at bugs.python.org (adgprogramming)
Date: Tue, 13 Oct 2009 20:50:37 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255467037.34.0.821767233478.issue6941@psf.upfronthosting.co.za>


adgprogramming <knd_adam at yahoo.com> added the comment:

Oh! And my OS is Windows XP SP3 Media Center Edition Version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Tue Oct 13 23:20:56 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 13 Oct 2009 21:20:56 +0000
Subject: [issue7115] extension module builds fail when using paths in the
	extension name
In-Reply-To: <1255386784.29.0.0870710106996.issue7115@psf.upfronthosting.co.za>
Message-ID: <1255468856.19.0.411451803375.issue7115@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Added complementary fix in r75395

----------
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7115>
_______________________________________

From report at bugs.python.org  Tue Oct 13 23:46:52 2009
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 13 Oct 2009 21:46:52 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1255470412.75.0.58502499886.issue4120@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

> It may actually be enough to just place the 
Microsoft.VC90.CRT.manifest file into the Python folder (the one with 
python.exe and the CRT DLLs).

I concur with what Christoph says, that is how the embedded 
installation works. However, the .pyd files are not in the Python main 
folder. And therefore they shouldn't have a manifest for the runtimes 
(because it will look in the current folder relative to the DLL/pyd), 
because then the runtimes of the main python.exe will be used (which 
can then be in the same folder as the 'embedded' MSVCR location).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 00:19:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 13 Oct 2009 22:19:30 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1255463823.3.0.0027328988228.issue4610@psf.upfronthosting.co.za>
Message-ID: <4AD4FCE5.3050709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I have a half finished implementation of this, in case anyone
> is interested.

Feel free to upload it here. I'm fairly skeptical that it is
possible to implement casing "correctly" in a locale-independent
way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Wed Oct 14 00:29:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 13 Oct 2009 22:29:33 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1255472973.56.0.508897159033.issue6603@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply (notice that the 2.6 branch is closed for 
anything but 2.6.3 regressions right now, so you may want to defer this 
after 2.6.4).

----------
assignee: loewis -> mark.dickinson
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Wed Oct 14 01:13:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Oct 2009 23:13:22 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255475602.49.0.855421564323.issue7111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please note that normally an error message is output, but of course it
doesn't display since stderr is invalid :-)

It's clearer if you close stdout instead:

$ ./python -c 'pass' >&-
Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor
Abandon

If we want to allow for closed {stdin, stdout, stderr}, I'm not sure
what the semantics should be. Should sys.std{in, out, err} be None? Or a
file object which always throws an error?

Under Python 2.x, you don't get a crash but the behaviour is quite
unhelpful anyway:

$ python -c 'print 1' >&-
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Wed Oct 14 01:21:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Oct 2009 23:21:58 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too
	large	for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <1255476118.41.0.279907801101.issue7112@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r75396 (trunk) and r75397 (py3k)
I'll check with the buildbots before I close this issue.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Wed Oct 14 01:28:24 2009
From: report at bugs.python.org (Terrence Cole)
Date: Tue, 13 Oct 2009 23:28:24 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1255476504.75.0.11436759768.issue6766@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

I get the same results on:
Python 2.6.2 (r262:71600, Sep 14 2009, 18:47:57)
[GCC 4.3.2] on linux2

I think this is the same issue I was seeing yesterday.  You can exercise
the issue and cause an exception with just 6 lines:

##### CODE #####
from multiprocessing import Manager
manager = Manager()
ns_proxy = manager.Namespace()
evt_proxy = manager.Event()
ns_proxy.my_event_proxy = evt_proxy
print ns_proxy.my_event_proxy

##### TRACEBACK #####
Traceback (most recent call last):
  File "test_nsproxy.py", line 39, in <module>
    print ns_proxy.my_event_proxy
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 989, in
__getattr__
    return callmethod('__getattribute__', (key,))
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 740, in
_callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError:
---------------------------------------------------------------------
Unserializable message: ('#RETURN', <threading._Event object at 0x1494790>)
---------------------------------------------------------------------

Storing a proxy into a proxied object and then accessing the proxy 
returns a copy of the object itself and not the stored proxy.  Thus,
updates to the nested dict are local and do not update the real object,
and proxies to unpicklable objects raise an exception when accessed.

----------
nosy: +terrence

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Wed Oct 14 01:40:55 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 13 Oct 2009 23:40:55 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too
	large	for 'long'
In-Reply-To: <1255476118.41.0.279907801101.issue7112@psf.upfronthosting.co.za>
Message-ID: <4AD51002.3090506@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Fixed with r75396 (trunk) and r75397 (py3k)

Thanks, Amaury.

> I'll check with the buildbots before I close this issue.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Wed Oct 14 02:11:13 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 14 Oct 2009 00:11:13 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255479073.96.0.2360005122.issue7111@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Is it even possible to portably test the validity of a file descriptor
without trying to write/read it?

When I first saw this bug, my gut feeling was "well, don't do that
then!"  However, I then recalled that Windows GUI applications have no
stdin, stdout, or stderr.  

Python 2 will raise IOError: Bad File Descriptor when the user tries to
write to stdout or stderr (more accurately, it raises the exception when
trying to flush data to the file descriptor).  

I just tested pythonw.exe.  If I set sys.stderr by hand to a file, then
write to sys.stdout, 2.6 will correctly write the exception to the file.
 3.1 exits silently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Wed Oct 14 02:33:05 2009
From: report at bugs.python.org (Terrence Cole)
Date: Wed, 14 Oct 2009 00:33:05 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1255480385.02.0.0766623832533.issue6766@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

When a manager receives a message, it unpickles the arguments; this
calls BaseProxy.__reduce__, which calls RebuildProxy.  If we are in the
manager, this returns the actual object, otherwise it returns a new
proxy.  If we naively disable the ability for proxied objects to be
unredirected in the manager, as in the attached svn diff, this solves
the problem that Carlos and I are seeing.  Surprisingly, after applying
this change, the full multiprocessing regression test still runs fine. 
I'm sure this change should have some greater impact, but I'm not sure
what.  I would appreciate if someone more knowledgeable could comment.

----------
keywords: +patch
Added file: http://bugs.python.org/file15119/mp_proxy_hack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:04:06 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 01:04:06 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Following my own (Twitter) advice I downloaded the 2.6.4rc1 release 
candidate and installed it on my x86 iMac running OS X 10.5.8, and tried 
to run a Google App Engine app with it.  Google App Engine prefers Python 
2.5, but so far it has always worked with 2.6 as well, modulo 1-2 
warnings.  But not 2.6.4rc1!  Even on a trivial app I get "RuntimeError: 
maximum recursion depth exceeded".  I'm attaching a file with the 
traceback (repetitive stuff elided).

I'd be happy to provide more details if they are needed to reproduce.  I'm 
using the Google App Engine SDK 1.2.6.

----------
components: Library (Lib)
files: traceback.txt
messages: 93952
nosy: gvanrossum
severity: normal
status: open
title: 2.6.4rc1 regression
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15120/traceback.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:06:16 2009
From: report at bugs.python.org (Bonnie Douglas)
Date: Wed, 14 Oct 2009 01:06:16 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255482376.25.0.664766506408.issue6941@psf.upfronthosting.co.za>


Bonnie Douglas <bonnie.douglas at biarri.com> added the comment:

The only other thing that I've done is change my firewall software.
I use Bullguard.  I had to use the Custom Security settings for the
Firewall, but set it to always allow pythonw.exe and python.exe access
to all ports.

A colleague of mine is also running XP and ditched IDLE because it kept
crashing.  I explained my reconfiguration of the firewall to him
yesterday but he hasn't implemented my changes yet so I can't report his
success/failure.

Notepad++ is a great editor to use with Python; it is Python-aware (and
it's free).  Another colleague uses it along with "print" in his code
for debugging.

Finally, our computer scientist recommends using Linux only.  Apparently
that solves all problems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:08:23 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 01:08:23 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255482503.57.0.335509566386.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

FWIW, I've ruled out App Engine SDK 1.2.6 as the source of the regression; 
on a MacBook Pro with the same OS 10.5.8 I get a similar traceback with 
SDK 1.2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:27:50 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Oct 2009 01:27:50 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255483670.7.0.410163892384.issue7120@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

How many lines are there in the traceback? Are there repetitions?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:36:49 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 01:36:49 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255484209.87.0.911403578487.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The full traceback had probably 1000 lines (or whatever the limit is); the 
piece between two calls to logging.warn() is repeated over and over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:40:05 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 14 Oct 2009 01:40:05 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1255484405.77.0.633282223089.issue6766@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Nothing jumps out to me off the top of my head - I can take a closer look 
at this after my pycon planning duties finish up in a few weeks. I agree 
this is unintended behavior. I'll need to audit the tests to make sure 
that A> This is being tested, and B> Those tests are not disabled.

When we included multiprocessing, some tests were deemed too unstable at 
the time, and we disabled. This was unfortunate, and I haven't been able 
to circle back and spend the time needed to refactor the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:47:37 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Oct 2009 01:47:37 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255484857.89.0.0986385183973.issue7120@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

App engine shows up after every import statement, so it must have some 
kind of import hook -- which can do evil things

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:48:19 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Oct 2009 01:48:19 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255484899.44.0.882247463223.issue7120@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:52:34 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 01:52:34 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255485154.72.0.766729642432.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yes, App Engine uses a PEP 302 style import hook to implement the sandbox.  
Could it be that there's a new module dependency introduced by 2.6.3-4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 03:58:57 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Oct 2009 01:58:57 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255485537.97.0.616988814891.issue7120@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

While I am not able to reproduce this by running 1.2.6 on Gentoo Linux
with Rietveld, I will make an educated guess that it is the "from
multiprocessing import current_process" line in r75130. I doubt this
module is available on app engine, so it tries to use logging.warn,
which tries to import multiprocessing...

----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 04:01:55 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 14 Oct 2009 02:01:55 +0000
Subject: [issue6403] distutils builds extension modules to root package
	directory
In-Reply-To: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
Message-ID: <1255485715.25.0.34029330802.issue6403@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6403>
_______________________________________

From report at bugs.python.org  Wed Oct 14 04:16:07 2009
From: report at bugs.python.org (Terrence Cole)
Date: Wed, 14 Oct 2009 02:16:07 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1255486567.94.0.77616307474.issue6766@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

The tests for the SyncManager are being automagically generated at
import time -- I was not quite able to follow that well enough to know
exactly what is getting tested, or if they are even enabled.  It did not
appear to contain any recursion, however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Wed Oct 14 04:17:29 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 14 Oct 2009 02:17:29 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1255486649.49.0.862776370579.issue6766@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Yeah, the auto-generation is too clever and needs to be pulled out 
entirely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Wed Oct 14 04:49:20 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 02:49:20 +0000
Subject: [issue7120] 2.6.4rc1 regression
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255488560.99.0.529551787705.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The dependency of logging on multiprocessing feels backwards.  But it's 
not actually a new regression, it seems that was there in 2.6.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 05:09:45 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Oct 2009 03:09:45 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255489785.39.0.762276331331.issue6941@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Wed Oct 14 05:37:15 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 03:37:15 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255491435.74.0.260785779426.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The addition of multiprocessing support to logging seems to have happened 
in 2.6.2; bad timing for a feature. :-(

----------
title: 2.6.4rc1 regression -> logging depends on multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 06:57:09 2009
From: report at bugs.python.org (mike)
Date: Wed, 14 Oct 2009 04:57:09 +0000
Subject: [issue7121] ImportError of urllib.request & http.client under
	PYTHONHOME/Lib
In-Reply-To: <1255496229.06.0.897594759505.issue7121@psf.upfronthosting.co.za>
Message-ID: <1255496229.06.0.897594759505.issue7121@psf.upfronthosting.co.za>


New submission from mike <mikezp59 at gmail.com>:

There's a python program in the attached file http.py, I import
urllib.request in http.py, and urllib.request imports http.client.

  When I try to run http.py by command "python http.py", the error is as
below:

Traceback (most recent call last):
  File "http.py", line 4, in <module>
    import urllib.request
  File "C:\Program Files\Python311\lib\urllib\request.py", line 86, in
<module>
    import http.client
  File "D:\program\python\http.py", line 6, in <module>
    response = urllib.request.urlopen('http://python.org/')
AttributeError: 'module' object has no attribute 'request'


   However, if I copy http.py to directory PYTHONHOME/Lib and run
command "python http.py" under directory PYTHONHOME/Lib, it works
successfully; if you move it to other directories and run the command,
the error will be returned.


   Note: the source code of http.py is copied from python311.chm under
directory PYTHONHOME/Doc.

----------
components: Library (Lib)
files: http.py
messages: 93965
nosy: mikezp59
severity: normal
status: open
title: ImportError of urllib.request & http.client under PYTHONHOME/Lib
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15121/http.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7121>
_______________________________________

From report at bugs.python.org  Wed Oct 14 07:22:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Oct 2009 05:22:44 +0000
Subject: [issue7121] ImportError of urllib.request & http.client under
	PYTHONHOME/Lib
In-Reply-To: <1255496229.06.0.897594759505.issue7121@psf.upfronthosting.co.za>
Message-ID: <1255497763.99.0.643126675643.issue7121@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Your file is named 'http.py'. When urllib.request tries to import
http.client your file ("D:\program\python\http.py") is picked up first
instead of the right one ('C:\Program Files\Python311\lib\http\client.py').
Your file is then executed again and when it calls urllib.request,
urllib has not been completely imported yet, so the call fails.
Try to use another name for your program.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7121>
_______________________________________

From report at bugs.python.org  Wed Oct 14 07:55:33 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 14 Oct 2009 05:55:33 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255499733.28.0.78291957074.issue7120@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I propose to fix it by just setting logRecord.processName to None for
now, which is what should happen if multiprocessing isn't available.

In environments where multiprocessing is not available,
logging.logMultiprocessing should be False, but that fix needs to go
into GAE, I guess?

Benjamin, I believe you added this change (in r70348), are you
comfortable with what I'm proposing? Anyone else have any objections?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 10:38:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Oct 2009 08:38:28 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255509508.73.0.982265302828.issue7120@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Whatever the value of logMultiprocessing is, I suggest to not import the
multiprocessing module if the application did not import it before:
something like:

    if "multiprocessing" in sys.modules:
        from multiprocessing import current_process
        self.processName = current_process().name
    else:
        # current_process().name returns this the first time
        self.processName = 'MainProcess'

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 10:56:38 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Oct 2009 08:56:38 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255510598.47.0.787303197485.issue7111@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> 3.1 exits silently.
Did you use "print"? pythonw.exe 3.1 sets sys.stdout to None.
if you use sys.stdout.write, you get an exception. But print() silently
does nothing if the file is None.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Wed Oct 14 11:54:42 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 14 Oct 2009 09:54:42 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1255514082.52.0.13794798195.issue5985@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is my experimental patch.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file15122/samefile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Wed Oct 14 11:55:13 2009
From: report at bugs.python.org (Peter Eisentraut)
Date: Wed, 14 Oct 2009 09:55:13 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1255514113.67.0.589752902426.issue7111@psf.upfronthosting.co.za>


Peter Eisentraut <peter_e at gmx.net> added the comment:

For what it's worth, the code in question is used here (using "import
distutils" instead of "pass"):

http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/config/python.m4?rev=1.15;content-type=text%2Fx-cvsweb-markup

This is obviously a completely gratuitous variant on 2>/dev/null, but it
has apparently been working since forever.  I'll probably go make the
change anyway.

Nevertheless, I think Python shouldn't core dump.  It may choose to exit
doing nothing (useful) if it doesn't want to deal with this case.

Check this for possible alternative behaviors:

$ ls 1>&-
ls: write error: Bad file descriptor
($? = 2)
$ ls 1>&- 2>&-
($? = 2, no output)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Wed Oct 14 12:00:40 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 14 Oct 2009 10:00:40 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255509508.73.0.982265302828.issue7120@psf.upfronthosting.co.za>
Message-ID: <494201.62032.qm@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Whatever the value of logMultiprocessing is, I suggest to not import the

> multiprocessing module if the application did not import it before:
> something like:
> 
>     if "multiprocessing" in sys.modules:
>         from multiprocessing import current_process
>         self.processName = current_process().name
>     else:
>         # current_process().name returns this the first time
>         self.processName = 'MainProcess'
> 

I suggested "None" because that was the value used in r70348 when logMultipocessing is False. I presume you're only talking about when it's True? I'm confused by your "Whatever the value of logMultiprocessing is, ...".

Should the system behaviour really change depending on whether multiprocessing was already imported? I can see why you're suggesting it but it makes me a little uneasy :-S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 13:22:51 2009
From: report at bugs.python.org (Erik Sandberg)
Date: Wed, 14 Oct 2009 11:22:51 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1255519371.87.0.392815563482.issue5985@psf.upfronthosting.co.za>


Erik Sandberg <sandberg at virtutech.com> added the comment:

An alternative solution which I would have considered, is to extend
stat/fstat on Windows to set st_dev and st_ino to sensible values (based
on dwVolumeSerialNumber and nFileIndexLow/High), and then use the POSIX
implementations of samefile/sameopenfile.

There may be one potential problem with this solution though: It would
require stat to perform a CreateFile in addition to GetFileAttributesEx,
and I don't know if there are situations where one is allowed to call
the latter but not the former on a file. There would be no such problems
with fstat, though.

In your patch, I think the dwShareMode parameter to CreateFile* should
be changed to FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE so
make the operation less intrusive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Wed Oct 14 13:31:28 2009
From: report at bugs.python.org (chuck)
Date: Wed, 14 Oct 2009 11:31:28 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1255519888.67.0.118736936127.issue7069@psf.upfronthosting.co.za>


chuck <jan.hosang at gmail.com> added the comment:

That's fine with me. Looks like nobody wants to check it in anyways.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7069>
_______________________________________

From report at bugs.python.org  Wed Oct 14 13:42:49 2009
From: report at bugs.python.org (Alex)
Date: Wed, 14 Oct 2009 11:42:49 +0000
Subject: [issue7122] multiprocessing.Pool() problem in windows
In-Reply-To: <1255520569.54.0.664062974628.issue7122@psf.upfronthosting.co.za>
Message-ID: <1255520569.54.0.664062974628.issue7122@psf.upfronthosting.co.za>


New submission from Alex <nabrozidhs at gmail.com>:

Maybe I didn't understand how multiprocessing works but when running the
test code below I get 200+ processes in Windows and it never finishes.
It works fine on Linux.

----------
components: Library (Lib)
files: prueba.py
messages: 93975
nosy: SirLalala
severity: normal
status: open
title: multiprocessing.Pool() problem in windows
versions: Python 2.6
Added file: http://bugs.python.org/file15123/prueba.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7122>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:00:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 12:00:51 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255521651.79.0.229494206922.issue7120@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

`self.processName` could be a lazily computed property, since it doesn't
seem to be used anywhere by default. Something like:

    _processName = None

    @property
    def processName(self):
        n = self._processName
        if n is not None:
            return n
        if 'multiprocessing' not in sys.modules:
            n = 'mainProcess'
        else:
            n = sys.modules['multiprocessing'].current_process().name
        self._processName = n
        return n


If you don't like the overhead of a property, you could do the caching
dance in a __getattr__ method instead.

NB : if 'multiprocessing' isn't in sys.modules, it means that you can
only be in the main process, as far as I understand. Processes launched
by multiprocessing itself *will* have 'multiprocessing' in sys.modules,
unless it is doing really weird stuff.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:04:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Oct 2009 12:04:12 +0000
Subject: [issue7122] multiprocessing.Pool() problem in windows
In-Reply-To: <1255520569.54.0.664062974628.issue7122@psf.upfronthosting.co.za>
Message-ID: <1255521852.81.0.039768829696.issue7122@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This difference between Unix and Windows is documented there:
http://docs.python.org/library/multiprocessing.html#windows
Please carefully read the paragraph named "Safe importing of main module".

You will certainly need to add a condition like
   if __name__ == '__main__':
so that subprocesses (which start a new Python interpreter from the
start) don't start another Pool themselves.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7122>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:14:52 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 12:14:52 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>


New submission from Peter Saunders <pajs at fodder.org.uk>:

I have an example code that works fine on Python 2.6.3, but when run in
Python 3.1.1 - after a very short period of time, will go wrong.

Summary:

We have a queue, and when the queue has something in it (a list), we
start a thread to deal with that entry.

The thread then runs a Process for every entry in the list we popped off
the queue. The Process target takes a Pipe, and it sends "True" back
down the pipe, and then exits. However, this Process never goes defunct,
and thus the Thread that started the Process never reaps it. When doing
a truss on the Process, it sits there in:

lwp_park(0x00000000, 0)         (sleeping...)

----------
files: testing.py
messages: 93978
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: Multiprocess Process does not always exit when run from a thread.
versions: Python 3.1
Added file: http://bugs.python.org/file15124/testing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:30:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 14 Oct 2009 12:30:10 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1255523410.31.0.583156026684.issue5985@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> extend stat/fstat on Windows to set st_dev and st_ino to sensible
> values (based on dwVolumeSerialNumber and nFileIndexLow/High)

Once I considered this approach, but problems was that
nFileIndexLow/High can change every time file handle is opened, so it's
not unique. See remarks in following page.
http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspx

> I think the dwShareMode parameter to CreateFile* should
> be changed to FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
> so make the operation less intrusive.

Probably you are right. I must admit I'm not familiar with this *shared*
flag, and I was careless about its usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:34:05 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 14 Oct 2009 12:34:05 +0000
Subject: [issue7124] idle.py -n : help() doesn't work in a reopened shell
	window
In-Reply-To: <1255523645.12.0.980684749685.issue7124@psf.upfronthosting.co.za>
Message-ID: <1255523645.12.0.980684749685.issue7124@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

The following procedure reveals a problem with help:

1) Start IDLE with -n option (no subprocess)
2) Create a script (e. g. helloworld one-liner
3) Run script
4) Close Shell Window
5) Via Menu: Run | Python Shell reopen Shell window
6) >>> help(print)
Help on ...
...
    end:  string appended after the last value, default a newline.
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    help(print)
  File "C:\Python31\lib\site.py", line 429, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Python31\lib\pydoc.py", line 1710, in __call__
    self.help(request)
  File "C:\Python31\lib\pydoc.py", line 1758, in help
    self.output.write('\n')
  File "C:\Python31\lib\idlelib\PyShell.py", line 1231, in write
    self.shell.write(s, self.tags)
  File "C:\Python31\lib\idlelib\PyShell.py", line 1212, in write
    self.text.mark_gravity("iomark", "right")
AttributeError: 'NoneType' object has no attribute 'mark_gravity'
>>> 

So in a re-opened Shell-Window in an IDLE in -n mode, help() doesn't
work correctly.

Regards,
Gregor

----------
components: IDLE
messages: 93980
nosy: gregorlingl
severity: normal
status: open
title: idle.py -n : help() doesn't work in a reopened shell window
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7124>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:51:21 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 12:51:21 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255524681.27.0.985043889406.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

Further information: it doesn't fail everytime in Python 3.1 - usually 1
in 4, or 1 in 5 times. It never fails with Python 2.6.3

Example output from the script when its failing (python 3.1):

Starting data1
Starting data2
Started subproc: PID: 20209 : args: data1
poll
Started subproc: PID: 20210 : args: data2
poll
Child has sent:True
poll
Child has sent:True
poll
isalive: False
isalive: True
Reaping PID: 20210
isalive: True
poll
Finishing: data2
isalive: True
poll
isalive: True
poll
isalive: True
poll
isalive: True
poll
<repeat isalive and poll lines until>:
isalive: True
poll
isalive: True
terminating
Child had to be killed due to a timeout
Finishing: data1
True

Working output (consistantly works on Python 2.6.3):
Starting data1
Starting data2
Started subproc: PID: 20252 : args: data1
poll
Started subproc: PID: 20253 : args: data2
poll
Child has sent:True
Child has sent:True
poll
Child has sent:True
poll
isalive: False
isalive: False
isalive: False
Reaping PID: 20252
Reaping PID: 20253
Finishing: data1
Finishing: data2
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:24:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 13:24:29 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255526669.49.0.253599535144.issue7058@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file15107/refactored_environment_checking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:26:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 13:26:05 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255526765.71.0.0952584355319.issue7058@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is an updated patch that doesn't break -j.

----------
Added file: http://bugs.python.org/file15125/refactored_environment_checking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:34:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 13:34:00 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255527240.81.0.896480862231.issue7058@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me. Not sure it should be backported though, the patch has
become really sizeable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:36:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 13:36:23 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1255527383.28.0.492978424.issue7058@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree about not backporting the new patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:41:09 2009
From: report at bugs.python.org (M Joonas Pihlaja)
Date: Wed, 14 Oct 2009 13:41:09 +0000
Subject: [issue1104249] configure doesn't set up CFLAGS properly
Message-ID: <1255527669.84.0.884409715622.issue1104249@psf.upfronthosting.co.za>


M Joonas Pihlaja <jpihlaja at cc.helsinki.fi> added the comment:

Here's a test case:

$ CFLAGS="--haflkhlaiuhfnafkghnaf" ./configure; make
[... configure does its thing... ]
[... make does its thing and completes successfully ...]

Expected result:  The build fails due to an unknown flag in CFLAGS.

Witnessed result:  CFLAGS is completely ignored.

----------
nosy: +joonas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1104249>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:50:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 13:50:10 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255528210.07.0.829157433278.issue7123@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
components: +Library (Lib)
nosy: +jnoller
priority:  -> normal
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:51:46 2009
From: report at bugs.python.org (Erik Carstensen)
Date: Wed, 14 Oct 2009 13:51:46 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1255528306.87.0.169039722998.issue5985@psf.upfronthosting.co.za>


Erik Carstensen <sandberg at virtutech.com> added the comment:

> Once I considered this approach, but problems was that
> nFileIndexLow/High can change every time file handle is opened, so
> it's not unique.

Ah, I see, then your approach makes sense.

There's another part of your patch that I don't understand:

+except ImportError: # not running on Windows - mock up something sensible
+    from posixpath import samefile # XXX

In what situations will this happen, and are we guaranteed in those
cases that samefile will be found in posixpath?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:03:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 14:03:43 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255529023.42.0.139505551518.issue7123@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Acccording to http://blogs.sun.com/chrisg/entry/lwp_park_and_lwp_unpark,
the lwp_park() call could point to a mutex which is waiting to be acquired.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:17:18 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 14:17:18 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255529838.38.0.786543737736.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

Well, if it helps, here is the output of the dtrace script from starting
of a loop with the failure, and stopping during the failure.

----------
Added file: http://bugs.python.org/file15126/dtrace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:18:45 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 14 Oct 2009 14:18:45 +0000
Subject: [issue7125] typo (English) in threading.py
In-Reply-To: <1255529925.22.0.614824582196.issue7125@psf.upfronthosting.co.za>
Message-ID: <1255529925.22.0.614824582196.issue7125@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

threading.py line 122:
"cannot release un-aquired lock" --> "cannot release un-acquired lock"

----------
components: Library (Lib)
messages: 93989
nosy: Yinon
severity: normal
status: open
title: typo (English) in threading.py
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7125>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:19:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 14:19:57 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255529997.99.0.824294891681.issue7123@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does it not happen if you call your checkAlive() function directly from
your main() function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:20:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 14:20:34 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1255530034.39.0.0864345341048.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With r75397:

test___all__ leaked [1, 1] references, sum=2
test_asyncore leaked [1, 0] references, sum=1
test_distutils leaked [0, 2] references, sum=2
test_httpservers leaked [-259, 0] references, sum=-259
test_os leaked [-23, 23] references, sum=0
test_pydoc leaked [0, -21] references, sum=-21
test_threaded_import leaked [1, 0] references, sum=1
test_urllib leaked [4, 4] references, sum=8
test_uuid leaked [6, 6] references, sum=12
test_urllib2_localnet leaked [240, -239] references, sum=1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:21:02 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 14 Oct 2009 14:21:02 +0000
Subject: [issue7125] typo (English) in threading.py
In-Reply-To: <1255529925.22.0.614824582196.issue7125@psf.upfronthosting.co.za>
Message-ID: <1255530062.4.0.725666099551.issue7125@psf.upfronthosting.co.za>


Yinon Ehrlich <yinoneh at users.sourceforge.net> added the comment:

just saw now that the word 'un-aquired' is repeated several times in the
threading module...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7125>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:48:11 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 14 Oct 2009 14:48:11 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1255531691.02.0.102774263878.issue5985@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'm not sure about this neither. So, XXX is in comment. ;-)

On abspath() above, it also tries to import native method
_getfullpathname(), and when it fails alternative implementation runs.
(probably when someone calls ntpath.abspath from linux or somewhere.....
Does it really happen? I don't know)

I was not sure what kind of alternative implementation is appropriate,
so I borrowed posixmodule's one. Probably more appropriate
implementation may exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:09:38 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 14 Oct 2009 15:09:38 +0000
Subject: [issue7126] Contradictory documentation for os.putenv and os.system
In-Reply-To: <1255532978.01.0.913860500332.issue7126@psf.upfronthosting.co.za>
Message-ID: <1255532978.01.0.913860500332.issue7126@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The documentation for os.putenv states that "changes to the environment
affect subprocesses started with os.system(), popen() or fork() and
execv()" and "assignments to items in os.environ are automatically
translated into corresponding calls to putenv()".

However, the documentation for os.system() states "Changes to os.environ
... are not reflected in the environment of the executed command."

A simple test confirms that the os.putenv documentation is the correct one:

Python 2.6
>>> import os
>>> os.environ['foo'] = 'bar'
>>> os.system('echo $foo')
bar
0
>>>

----------
assignee: georg.brandl
components: Documentation
messages: 93994
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: Contradictory documentation for os.putenv and os.system
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7126>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:12:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 15:12:43 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255533163.19.0.414440486255.issue7123@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As for the dtrace output: I'm not a Solaris expert unfortunately, I was
just trying to suggest a possible direction for diagnosing this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:18:27 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 15:18:27 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255533507.91.0.473589551371.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

If you mean, in main() instead of doing:

while True:
    q.put(["data1", "data2"])
    t = Process(target=popJobs, args=(q, ))
    t.start()
    t.join()

and doing:

while True:
    q.put(["data1", "data2"])
    popJobs(q)

instead. Then, the bug does indeed occur the same way. It did take more
iterations before it occured however. 

If however, you meant:

while True:
   fail=failureObject()
   for x in ["data1", "data2"]:
       checkAlive(fail, x)
   print(fail.status())

Then the bug never occurs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:21:24 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 15:21:24 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255533684.67.0.992581575249.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

Same thing occurs, as you would expect, when I do:

while True:
    fail=failureObject()
    tlist = []
    for x in ["data1", "data2"]:
        t = threading.Thread(target=checkAlive, args = (fail, x), name=x)
        t.start()
        tlist.append(t)

    for x in tlist:
        t.join()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:47:24 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 15:47:24 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255535244.69.0.99612326183.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

Further oddness:

When running the script (i've reduced its size further now, see attached):

I get the following output:

Reaping PID: 23215
True
Started subproc: PID: 23216 : args: data1
Started subproc: PID: 23216 : args: data1
Started subproc: PID: 23217 : args: data2
poll
isalive: True
isalive: True
poll


Notice the Started subprod of the SAME PID and the Same args twice, yet
this print only occurs once in the code, and I can't see how this should
happen?

----------
Added file: http://bugs.python.org/file15127/testing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:52:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Oct 2009 15:52:41 +0000
Subject: [issue7125] typo (English) in threading.py
In-Reply-To: <1255529925.22.0.614824582196.issue7125@psf.upfronthosting.co.za>
Message-ID: <1255535561.08.0.00244387646594.issue7125@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r75402. Not backporting, since an exception message is changed.

Thanks!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7125>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:54:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 15:54:46 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255535244.69.0.99612326183.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255535912.5634.13.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Notice the Started subprod of the SAME PID and the Same args twice, yet
> this print only occurs once in the code, and I can't see how this should
> happen?

This is a thread-safety issue in sys.stdout/stderr, it will be fixed in
3.1.2 (see issue6750).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:58:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Oct 2009 15:58:02 +0000
Subject: [issue7126] Contradictory documentation for os.putenv and os.system
In-Reply-To: <1255532978.01.0.913860500332.issue7126@psf.upfronthosting.co.za>
Message-ID: <1255535882.82.0.51042882132.issue7126@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75403.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7126>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:04:28 2009
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 14 Oct 2009 16:04:28 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255536268.83.0.995352317048.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

Sorry for the spam on the updates :) - but, its the same thread printing
this out too. I changed the print line to:

curThread = threading.current_thread()
print("Started subproc: PID: %d : args: %s Thread ID: %s" %(newJob.pid,
str(args), str(curThread.ident)))

and got the output:

Reaping PID: 23707
True
Started subproc: PID: 23709 : args: data1 Thread ID: 12
Started subproc: PID: 23709 : args: data1 Thread ID: 12
poll
isalive: True
Started subproc: PID: 23710 : args: data2 Thread ID: 13
poll
isalive: True

Again, I can't see how this could pring it out twice? Could this be
related to the problem we are having? Altgough I do seem to get the line
twice on 2.6.3 as well - but nothing like as often..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:07:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 16:07:03 +0000
Subject: [issue7127] regrtest -j fails when tests write to stderr
In-Reply-To: <1255536423.67.0.1834189118.issue7127@psf.upfronthosting.co.za>
Message-ID: <1255536423.67.0.1834189118.issue7127@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

If a test writes to stderr, then the -j (multiprocessing) support in
regrtest fails to correctly extract the JSON data from the test output,
resulting in a JSON traceback followed by a failure of the worker
thread.  Antoine has suggested tagging the JSON result string with a
prefix and looking for that prefix, instead of the current method (which
assumes that the JSON result string is at the end of the output from the
test).

----------
components: Tests
keywords: easy
messages: 94003
nosy: pitrou, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: regrtest -j fails when tests write to stderr
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7127>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:12:34 2009
From: report at bugs.python.org (Joseph C Wang)
Date: Wed, 14 Oct 2009 16:12:34 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>


New submission from Joseph C Wang <joequant at gmail.com>:

When running cPickle in restricted mode, the module tries to import
copyreg which does not appear to exist anywhere.  The problem is in
cPickle.c 

 2980 	if (PyEval_GetRestricted()) {
 2981 		/* Restricted execution, get private tables */
 2982 		PyObject *m = PyImport_Import(copyreg_str);
 2983 
 2984 		if (m == NULL)
 2985 			goto err;
 2986 		self->dispatch_table = PyObject_GetAttr(m, dispatch_table_str);
 2987 		Py_DECREF(m);
 2988 		if (self->dispatch_table == NULL)
 2989 			goto err;
 2990 	}
 2991 	else {
 2992 		self->dispatch_table = dispatch_table;
 2993 		Py_INCREF(dispatch_table);
 2994 	}

copyreg_str should probably be copy_reg_str

----------
components: Interpreter Core
messages: 94004
nosy: joequant
severity: normal
status: open
title: cPickle looking for non-existent package copyreg
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:50:44 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 14 Oct 2009 16:50:44 +0000
Subject: [issue7091] Distutils build ignores the --compiler command line option
In-Reply-To: <1255092628.15.0.61454939103.issue7091@psf.upfronthosting.co.za>
Message-ID: <1255539044.78.0.766024528477.issue7091@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Duplicate of #7068

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> 2.6.3 does not use specified compiler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7091>
_______________________________________

From report at bugs.python.org  Wed Oct 14 19:14:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Oct 2009 17:14:44 +0000
Subject: [issue7112] unicodetype_db.h warning: integer constant is too
	large	for 'long'
In-Reply-To: <1255348609.65.0.0972853196625.issue7112@psf.upfronthosting.co.za>
Message-ID: <1255540484.65.0.598023211415.issue7112@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7112>
_______________________________________

From report at bugs.python.org  Wed Oct 14 19:19:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 17:19:30 +0000
Subject: [issue7065] bytes.maketrans segfaults
In-Reply-To: <1254747203.73.0.94763018002.issue7065@psf.upfronthosting.co.za>
Message-ID: <1255540770.83.0.884097538857.issue7065@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r75404 and r75406. Thanks!

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7065>
_______________________________________

From report at bugs.python.org  Wed Oct 14 19:52:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Oct 2009 17:52:02 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1255542722.79.0.216279270585.issue7069@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7069>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:33:01 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 14 Oct 2009 18:33:01 +0000
Subject: [issue7129] 'filling' missing in __all__
In-Reply-To: <1255545181.33.0.710014899763.issue7129@psf.upfronthosting.co.za>
Message-ID: <1255545181.33.0.710014899763.issue7129@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

By oversight the turtle graphics function filling is missing in the
__all__ list which is composed by several parts, among them
_tg_turtle_functions.

So 'filling' has to be added to _tg_turtle_functions

a path is attached

----------
components: Library (Lib)
files: filling-bug.diff
keywords: patch
messages: 94007
nosy: georg.brandl, gregorlingl, loewis
severity: normal
status: open
title: 'filling' missing in __all__
type: resource usage
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15128/filling-bug.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7129>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:36:26 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 14 Oct 2009 18:36:26 +0000
Subject: [issue7129] 'filling' missing in __all__ ot turtle.py
In-Reply-To: <1255545181.33.0.710014899763.issue7129@psf.upfronthosting.co.za>
Message-ID: <1255545386.98.0.862840919083.issue7129@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


----------
title: 'filling' missing in __all__ -> 'filling' missing in __all__ ot turtle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7129>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:46:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Oct 2009 18:46:32 +0000
Subject: [issue7129] 'filling' missing in __all__ ot turtle.py
In-Reply-To: <1255545181.33.0.710014899763.issue7129@psf.upfronthosting.co.za>
Message-ID: <1255545992.05.0.174575206569.issue7129@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r75416.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7129>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:48:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Oct 2009 18:48:43 +0000
Subject: [issue7116] str.join() should be documented as taking an iterable
In-Reply-To: <1255387061.17.0.69385266786.issue7116@psf.upfronthosting.co.za>
Message-ID: <1255546123.0.0.510190190355.issue7116@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75418.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7116>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:54:04 2009
From: report at bugs.python.org (Dino Viehland)
Date: Wed, 14 Oct 2009 18:54:04 +0000
Subject: [issue7130] json uses sre_* modules which may not work on alternate
	implemenations
In-Reply-To: <1255546444.41.0.18277225487.issue7130@psf.upfronthosting.co.za>
Message-ID: <1255546444.41.0.18277225487.issue7130@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

Currently the json module is using the sre_* modules to construct it's 
regular expressions instead of just using the re module directly.  

Because of this it's taking a dependency on what would appear to be 
CPython specific implementation details (sre_* appear to be 
undocumented) and a deprecated module.  The end result is that json 
decoding doesn't work on IronPython and may not work on other Python 
implementations.

----------
components: Library (Lib)
messages: 94010
nosy: DinoV
severity: normal
status: open
title: json uses sre_* modules which may not work on alternate implemenations
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7130>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:00:15 2009
From: report at bugs.python.org (Jeff Senn)
Date: Wed, 14 Oct 2009 19:00:15 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>
Message-ID: <1255546815.92.0.62328909151.issue4610@psf.upfronthosting.co.za>


Jeff Senn <senn at users.sourceforge.net> added the comment:

> Feel free to upload it here. I'm fairly skeptical that it is
> possible to implement casing "correctly" in a locale-independent
> way.

Ok. I will try to find time to complete it enough to be readable.

Unicode (see sec 3.13) specifies the casing of unicode strings pretty 
completely -- i.e. it gives "Default Casing" rules to be used when no 
locale specific "tailoring" is available.  The only dependencies on 
locale for the special casing rules are for Turkish, Azeri, and 
Lithuanian.  And you only need to know that that is the language, no 
other details.  So I'm sure that a complete implementation is possible 
without resort to a lot of locale munging -- at least for .lower() 
.upper() and .title().

.swapcase() is just ...err... dumb^h^h^h^h questionably useful. 

However .capitalize() is a bit weird; and I'm not sure it isn't 
incorrectly implemented now:

It UPPERCASES the first character, rather than TITLECASING, which is 
probably wrong in the very few cases where it makes a difference:
e.g. (using Croatian ligatures)

>>> u'\u01c5amonjna'.title()
u'\u01c4amonjna'
>>> u'\u01c5amonjna'.capitalize()
u'\u01c5amonjna'

"Capitalization" is not precisely defined (by the Unicode standard) -- 
the currently python implementation doesn't even do what the docs say: 
"makes the first character have upper case" (it also lower-cases all 
other characters!), however I might argue that a more useful 
implementation "makes the first character have titlecase..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:14:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 19:14:11 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255547651.32.0.511945379366.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've fixed a bunch of them: aifc (r75407), test_atexit (r75408), bsddb
(r75409), test_calendar (r75410), StringIO (r75411), socket (r75412),
sndhdr (r75413), test_memoryio (r75415), test_profilehooks (r75417),
test_random (r75419), httplib (r75420), uuid (r75421).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:15:12 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 14 Oct 2009 19:15:12 +0000
Subject: [issue1754094] Tighter co_stacksize computation in stackdepth_walk
Message-ID: <1255547712.57.0.886882847621.issue1754094@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Committed to the Python 2.x and 3.x trunks.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754094>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:18:43 2009
From: report at bugs.python.org (Dieter Verfaillie)
Date: Wed, 14 Oct 2009 19:18:43 +0000
Subject: [issue7131] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1255547923.17.0.905503258872.issue7131@psf.upfronthosting.co.za>
Message-ID: <1255547923.17.0.905503258872.issue7131@psf.upfronthosting.co.za>


New submission from Dieter Verfaillie <dieterv at optionexplicit.be>:

Using Python 2.6.3 on Windows XP, distutils fails building an extension
module when mingw32 is specified as the compiler. Distutils fails with
the error message "Unable to find vcvarsall.bat".

Looking back in the subversion history for the distutils build_ext
command
(http://svn.python.org/view/python/tags/r263/Lib/distutils/command/build_ext.py?view=log)
I've found that line 306 has been changed in revision 72594 to read:
    self.compiler = new_compiler(compiler=None,

reverting back to revision 72586, so the code reads:
    self.compiler = new_compiler(compiler=self.compiler,

seems to fix the problem.

----------
assignee: tarek
components: Distutils, Windows
messages: 94014
nosy: dieterv, tarek
severity: normal
status: open
title: Extension module build fails for MinGW: missing vcvarsall.bat
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7131>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:20:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 19:20:49 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255548049.07.0.879419276772.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a record of stderr after a new regrtest run.

----------
Added file: http://bugs.python.org/file15129/stderr.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:21:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 19:21:30 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255548090.19.0.732983894961.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(interestingly, one of the culprits for py3k warnings is lib2to3)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:24:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Oct 2009 19:24:38 +0000
Subject: [issue7110] Output test failures on stderr in regrtest.py
In-Reply-To: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
Message-ID: <1255548278.71.0.119088963913.issue7110@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7110>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:25:30 2009
From: report at bugs.python.org (Jeff Senn)
Date: Wed, 14 Oct 2009 19:25:30 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>
Message-ID: <1255548330.08.0.951222721211.issue4610@psf.upfronthosting.co.za>


Jeff Senn <senn at users.sourceforge.net> added the comment:

Yikes! I just noticed that u''.title() is really broken! 

It doesn't really pay attention to word breaks -- 
only characters that "have case".  
Therefore when there are (caseless)
combining characters in a word it's really broken e.g.

>>> u'n\u0303on\u0303e'.title()
u'N\u0303On\u0303E'

That is (where '~' is combining-tilde-over)
n~on~e -title-cases-to-> N~On~E

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:25:51 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 14 Oct 2009 19:25:51 +0000
Subject: [issue6855] ihooks support for relative imports
In-Reply-To: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za>
Message-ID: <1255548351.77.0.628385974158.issue6855@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I've been using this version of ihooks for some time and it seems to
work fine. Committing the patch.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6855>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:26:55 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 14 Oct 2009 19:26:55 +0000
Subject: [issue4152] ihooks module cannot handle absolute imports
In-Reply-To: <1224524202.33.0.257355673326.issue4152@psf.upfronthosting.co.za>
Message-ID: <1255548415.18.0.222104450105.issue4152@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Fixed in SVN rev 75423.

----------
nosy: +nascheme
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4152>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:41:51 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 14 Oct 2009 19:41:51 +0000
Subject: [issue1101399] dict subclass breaks cPickle noload()
Message-ID: <1255549311.15.0.673670271743.issue1101399@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Applied to 2.x trunk. The 3.x version _pickle.c doesn't have the noload
 method.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1101399>
_______________________________________

From report at bugs.python.org  Wed Oct 14 21:54:04 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 14 Oct 2009 19:54:04 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255550044.41.0.0879986074586.issue7120@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into release26-maint (r75425). Please verify in GAE
environment, will make same fix in trunk and py3k once verified.

Fixed based on Antoine's message, though not identical to his posted code.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:08:16 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 20:08:16 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>


New submission from Philippe Verdy <verdy_p at wanadoo.fr>:

For now, when capturing groups are used within repetitions, it is impossible to capure what they match 
individually within the list of matched repetitions.

E.g. the following regular expression:

(0|1[0-9]{0,2}|2(?:[0-4][0-9]?|5[0-5]?)?)(?:\.(0|1[0-9]{0,2}|2(?:[0-4][0-9]?|5[0-5]?)?)){3}

is a regexp that contains two capturing groups (\1 and \2), but whose the second one is repeated (3 times) to 
match an IPv4 address in dotted decimal format. We'd like to be able to get the individual multiple matchs 
for the second group.

For now, capturing groups don't record the full list of matches, but just override the last occurence of the 
capturing group (or just the first if the repetition is not greedy, which is not the case here because the 
repetition "{3}" is not followed by a "?"). So \1 will effectively return the first decimal component of the 
IPv4 address, but \2 will just return the last (fourth) decimal component.


I'd like to have the possibility to have a compilation flag "R" that would indicate that capturing groups 
will not just return a single occurence, but all occurences of the same group. If this "R" flag is enabled, 
then:

- the Match.group(index) will not just return a single string but a list of strings, with as many occurences 
as the number of effective repetitions of the same capturing group. The last element in that list will be the 
one equal to the current behavior

- the Match.start(index) and Match.end(index) will also both return a list of positions, those lists having 
the same length as the list returned by Match.group(index).

- for consistency, the returned values as lists of strings (instead of just single strings) will apply to all 
capturing groups, even if they are not repeated.


Effectively, with the same regexp above, we will be able to retreive (and possibily substitute):

- the first decimal component of the IPv4 address with "{\1:1}" (or "{\1:}" or "{\1}" or "\1" as before), 
i.e. the 1st (and last) occurence of capturing group 1, or in Match.group(1)[1], or between string positions Match.start(1)[1] and Match.end(1)[1] ;

- the second decimal component of the IPv4 address with "{\2:1}", i.e. the 1st occurence of capturing group 
2, or in Match.group(2)[1], or between string positions Match.start(2)[1] and Match.end(2)[1] ;

- the third decimal component of the IPv4 address with "{\2:2}", i.e. the 2nd occurence of capturing group 2, 
or in Match.group(2)[2], or between string positions Match.start(2)[2] and Match.end(2)[2] ;

- the fourth decimal component of the IPv4 address with "{\2:3}" (or "{\2:}" or "{\2}" or "\2"), i.e. the 3rd 
(and last) occurence of capturing group 2, or in Match.group(2)[2], or between string positions 
Match.start(2)[3] and Match.end(2)[3] ;


This should work with all repetition patterns (both greedy and not greedy, atomic or not, or possessive), in 
which the repeated pattern contains any capturing group.


This idea should also be submitted to the developers of the PCRE library (and Perl from which they originate, 
and PHP where PCRE is also used), so that they adopt a similar behavior in their regular expressions.

If there's already a candidate syntax or compilation flag in those libraries, this syntax should be used for 
repeated capturing groups.

----------
components: Library (Lib)
messages: 94022
nosy: verdy_p
severity: normal
status: open
title: Regexp: capturing groups in repetitions
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:16:29 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 14 Oct 2009 20:16:29 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1255548330.08.0.951222721211.issue4610@psf.upfronthosting.co.za>
Message-ID: <4AD6319D.3090601@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jeff Senn wrote:
> 
> Jeff Senn <senn at users.sourceforge.net> added the comment:
> 
> Yikes! I just noticed that u''.title() is really broken! 
> 
> It doesn't really pay attention to word breaks -- 
> only characters that "have case".  
> Therefore when there are (caseless)
> combining characters in a word it's really broken e.g.
> 
>>>> u'n\u0303on\u0303e'.title()
> u'N\u0303On\u0303E'
> 
> That is (where '~' is combining-tilde-over)
> n~on~e -title-cases-to-> N~On~E

Please have a look at http://bugs.python.org/issue6412 - that patch
addresses many casing issues, at least up the extent that we can
actually fix them without breaking code relying on:

len(s.upper()) == len(s)

for upper/lower/title.

If we add support for 1-n code point mappings, then we can only
enable this support by using an option to the casing methods (perhaps
not a bad idea: the parameter could be used to signal the local
to assume).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:26:11 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 14 Oct 2009 20:26:11 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1255546815.92.0.62328909151.issue4610@psf.upfronthosting.co.za>
Message-ID: <4AD633E4.9010301@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jeff Senn wrote:
> However .capitalize() is a bit weird; and I'm not sure it isn't 
> incorrectly implemented now:
> 
> It UPPERCASES the first character, rather than TITLECASING, which is 
> probably wrong in the very few cases where it makes a difference:
> e.g. (using Croatian ligatures)
> 
>>>> u'\u01c5amonjna'.title()
> u'\u01c4amonjna'
>>>> u'\u01c5amonjna'.capitalize()
> u'\u01c5amonjna'
> 
> "Capitalization" is not precisely defined (by the Unicode standard) -- 
> the currently python implementation doesn't even do what the docs say: 
> "makes the first character have upper case" (it also lower-cases all 
> other characters!), however I might argue that a more useful 
> implementation "makes the first character have titlecase..."

You don't have to worry about .capitalize() and .swapcase() :-)

Those methods are defined by their implementation and don't resemble
anything defined in Unicode.

I agree that they are, well, not that useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:36:51 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 20:36:51 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255552611.64.0.890311202058.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

I'd like to add that the same behavior should also affect the span(index) 
method of MatchObject, that should also not just return a single (start, 
end) pair, but that should in this case return a list of pairs, one for 
each occurence, when the "R" compilation flag is specified.

This also means that the regular expression compilation flag R should be 
supported as these constants:
Regexp.R, or Regexp.REPETITIONS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:40:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Oct 2009 20:40:32 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>
Message-ID: <1255552832.07.0.18668404646.issue4610@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> .swapcase() is just ...err... dumb^h^h^h^h questionably useful. 

FWIW, it appears that the original use case (as an Emacs macro) was to
correct blocks of text where touch typists had accidentally left the
CapsLocks key turned on:  tHE qUICK bROWN fOX jUMPED oVER tHE lAZY dOG.

I agree with the rest of you that Python would be better-off without
swapcase().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:40:53 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 14 Oct 2009 20:40:53 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1255552853.61.0.0796282276688.issue812369@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Does this patch fix issue1545463 by any chance?  I am away from a 
development box ATM and cannot test the patch myself.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:44:16 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 14 Oct 2009 20:44:16 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1255553056.94.0.442013126077.issue812369@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:46:49 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Oct 2009 20:46:49 +0000
Subject: [issue6855] ihooks support for relative imports
In-Reply-To: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za>
Message-ID: <1255553209.79.0.425901217225.issue6855@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Sorry I didn't get to this, Neil.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6855>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:49:19 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 20:49:19 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255553359.77.0.181382541582.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

Rationale for the compilation flag:

You could think that the compilation flag should not be needed. However, 
not using it would mean that a LOT of existing regular expressions that 
already contain capturing groups in repetitions, and for which the 
caputiring group is effectively not used and should have been better 
encoded as a non-capuring group like (?:X) instead of (X), will suffer a 
negative performance impact and a higher memory usage.

The reason is that the MatchObject will have to store lists of 
(start,end) pairs instead of just a single pair: using a list will not 
be the default, so MatchObject.group(groupIndex), 
MatchObject.start(groupIndex), MatchObject.end(groupIndex), and 
MatchObject.span(groupIndex) will continue to return a single value or 
single pair, when the R compilation flag is not set (these values will 
continue to return only the last occurence, that will be overriden after 
each matched occurence of the capturing group.

The MatchObject.groups() will also continue to return a list of single 
strings without that flag set (i.e. a list of the last occurence of each 
capturing group). But when the R flag will be specified, it will return, 
instead, a list of lists, each element being for the group with the same 
index and being itself a list of strings, one for each occurence of the 
capturing group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:55:54 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 20:55:54 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255553754.28.0.0426434001035.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

Implementation details:

Currently, the capturing groups behave quite randomly in the values returned by MachedObject, when backtracking occurs in a repetition. This 
proposal will help fix the behavior, because it will also be much easier 
to backtrack cleanly, occurence by occurence, by just dropping the last 
element in the list of (start,end) pairs stored in the MatchedObject for 
all capturing groups specified WITHIN the repeated sub-expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:01:23 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Oct 2009 21:01:23 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255554083.75.0.0969696859041.issue7132@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:07:30 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 21:07:30 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255554450.79.0.732954745473.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Confirmed, the stack limit error is gone now. Thanks!!

(There's another error, the import of _scproxy from urllib, but that's 
easily added to the App Engine SDK's whitelist. I am still concerned 
about the amount of change in the 2.6 branch, but the cat is out of the 
bag.)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:15:13 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Oct 2009 21:15:13 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255554913.49.0.0496259289083.issue7120@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

(I don't know why the tracker reopened the issue when I added a comment. 
Anyway, is the fix going into 2.6.4 or will it have to wait for 2.6.5?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:20:42 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 14 Oct 2009 21:20:42 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1255555242.26.0.379952929521.issue812369@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

It should fix issue1545463 and running a quick test seems to show that
it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:36:25 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Oct 2009 21:36:25 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255556185.57.0.645582598879.issue7132@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm skeptical about what you are proposing for the following reasons:
1) it doesn't exist in any other implementation that I know;
2) if implemented as default behavior:
   * it won't be backward-compatible;
   * it will increase the complexity;
3) it will be a proprietary extension and it will reduce the
compatibility with other implementations;
4) I can't think to any real word situation where this would be really
useful.

Using a flag like re.R to change the behavior might solve the issue 2),
but I'll explain why I don't think this is useful.

Let's take a simpler ipv4 address as example: you may want to use
'^(\d{1,3})(?:\.(\d{1,3})){3}$' to capture the digits (without checking
if they are in range(256)).
This currently only returns:
>>> re.match('^(\d{1,3})(?:\.(\d{1,3})){3}$', '192.168.0.1').groups()
('192', '1')

If I understood correctly what you are proposing, you would like it to
return (['192'], ['168', '0', '1']) instead. This will also require an
additional step to join the two lists to get the list with the 4 values.

In these situations where some part is repeating, it's usually easier to
use re.findall() or re.split() (or just a plain str.split for simple
cases like this):
>>> addr = '192.168.0.1'
>>> re.findall('(?:^|\.)(\d{1,3})', addr)
['192', '168', '0', '1']
>>> re.split('\.', addr) # no need to use re.split here
['192', '168', '0', '1']

In both the examples a single step is enough to get what you want
without changing the existing behavior.

'^(\d{1,3})(?:\.(\d{1,3})){3}$' can still be used to check if the string
has the right "format", before using the other methods to extract the data.

So I'm -1 about the whole idea and -0.8 about an additional flag.
Maybe you should discuss about this on the python-ideas ML.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:46:21 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 14 Oct 2009 21:46:21 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255554913.49.0.0496259289083.issue7120@psf.upfronthosting.co.za>
Message-ID: <881066.76475.qm@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Guido van Rossum  added the comment:

> 
> (I don't know why the tracker reopened the issue when I added a comment. 
> Anyway, is the fix going into 2.6.4 or will it have to wait for 2.6.5?)

That's OK, I'll close it once I've made the same changes in trunk and py3k.

In terms of when the fix goes in, I guess it's Barry's call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:50:36 2009
From: report at bugs.python.org (Jeff Senn)
Date: Wed, 14 Oct 2009 21:50:36 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1255557036.41.0.460138244993.issue6412@psf.upfronthosting.co.za>


Jeff Senn <senn at users.sourceforge.net> added the comment:

Referred to this from issue 4610... anyone following this might want to 
look there as well.

----------
nosy: +senn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:55:24 2009
From: report at bugs.python.org (Jeff Senn)
Date: Wed, 14 Oct 2009 21:55:24 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1255557324.34.0.866242039336.issue6412@psf.upfronthosting.co.za>


Jeff Senn <senn at users.sourceforge.net> added the comment:

So, is it not considered a bug that:

>>> "This isn't right".title()
"This Isn'T Right"

!?!?!?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:26:47 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 22:26:47 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255559207.92.0.338390257354.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

You're wrong, it WILL be compatible, because it is only conditioned by a 
FLAG. The flag is there specifically for instructing the parser to 
generate lists of values rather than single values.

Without the regular compilation flag set, as I said, there will be NO 
change.

Reopening the proposal, which is perfectly valid !

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:28:31 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 14 Oct 2009 22:28:31 +0000
Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed
In-Reply-To: <1255557324.34.0.866242039336.issue6412@psf.upfronthosting.co.za>
Message-ID: <4AD65090.1020003@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jeff Senn wrote:
> 
> Jeff Senn <senn at users.sourceforge.net> added the comment:
> 
> So, is it not considered a bug that:
> 
>>>> "This isn't right".title()
> "This Isn'T Right"
> 
> !?!?!?

That's http://bugs.python.org/issue7008 and is fixed as part of
http://bugs.python.org/issue6412

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:29:26 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 22:29:26 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255559366.46.0.0935956040536.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

Note that I used the IPv4 address format only as an example. There are 
plenty of other more complex cases for which we really need to capture the 
multiple occurences of a capturing group within a repetition.

I'm NOT asking you how to parse it using MULTIPLE regexps and functions. 
Of course you can, but this is a distinct problem, but certinaly NOT a 
general solution (your solution using split() will NOT work with really A 
LOT of other regular expressions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:29:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 22:29:37 +0000
Subject: [issue7130] json uses sre_* modules which may not work on alternate
	implemenations
In-Reply-To: <1255546444.41.0.18277225487.issue7130@psf.upfronthosting.co.za>
Message-ID: <1255559377.41.0.51758613683.issue7130@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This doesn't seem true on trunk/py3k (2.7, 3.2) anymore. Please reopen
if I'm wrong.

----------
nosy: +bob.ippolito, pitrou
resolution:  -> out of date
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7130>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:31:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 22:31:59 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1255559519.02.0.153911011851.issue7128@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +easy
priority:  -> high
stage:  -> needs patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:32:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 22:32:54 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <881066.76475.qm@web25803.mail.ukl.yahoo.com>
Message-ID: <Pine.LNX.4.64.0910141827420.18193@kimball.webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Wed, 14 Oct 2009 at 21:46, Vinay Sajip wrote:
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>> Guido van Rossum  added the comment:
>>
>> (I don't know why the tracker reopened the issue when I added a comment.
>> Anyway, is the fix going into 2.6.4 or will it have to wait for 2.6.5?)

If a ticket is set to pending, any comment addition changes it back
to open.  The idea is that you set a ticket to 'pending feedback',
and if there is no feedback for time X, the ticket gets closed.
(An auto-close-pending feature has been proposed, but I don't think it
has been implemented yet.)

> In terms of when the fix goes in, I guess it's Barry's call.

Well, your commit to the 2.6 branch puts it into the next RC unless
someone (eg Barry) reverts it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:33:57 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 22:33:57 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255559637.6.0.598195439585.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

In addition, your suggested regexp for IPv4:

'^(\d{1,3})(?:\.(\d{1,3})){3}$'

is completely WRONG ! It will match INVALID IPv4 address formats like 
"000.000.000.000". Reread the RFCs... because "000.000.000.000" is 
CERTAINLY NOT an IPv4 address (if it is found in an URL) but a domain name 
that must be resolved into an IP address using domain name resolution 
requests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:41:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 22:41:12 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is due to r75412 (yes, mine). The proper fix would be to add
support for the new buffer API to the _ssl module.


testSocketServer (test.test_ssl.ThreadedTests) ... 
 server (('127.0.0.1', 52011):52011 ('AES256-SHA', 'TLSv1/SSLv3', 256)):
   [15/Oct/2009 00:42:18] "GET /keycert.pem HTTP/1.0" 200 -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 48099)
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 282, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 308, in
process_request
    self.finish_request(request, client_address)
  File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 321, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 639, in
__init__
    self.finish()
  File "/home/antoine/cpython/__svn__/Lib/SocketServer.py", line 692, in
finish
    self.wfile.flush()
  File "/home/antoine/cpython/__svn__/Lib/socket.py", line 300, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 203, in sendall
    v = self.send(data[count:])
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 94, in <lambda>
    self.send = lambda data, flags=0: SSLSocket.send(self, data, flags)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 174, in send
    v = self._sslobj.write(data)
TypeError: must be string or read-only buffer, not memoryview
----------------------------------------

Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_ssl.py", line 972,
in testSocketServer
    f = urllib.urlopen(url)
  File "/home/antoine/cpython/__svn__/Lib/urllib.py", line 87, in urlopen
    return opener.open(url)
  File "/home/antoine/cpython/__svn__/Lib/urllib.py", line 206, in open
    return getattr(self, name)(url)
  File "/home/antoine/cpython/__svn__/Lib/urllib.py", line 445, in
open_https
    'got a bad status line', None)
IOError: ('http protocol error', 0, 'got a bad status line', None)
ERROR

----------
assignee: pitrou
components: Extension Modules, Tests
messages: 94044
nosy: janssen, pitrou
severity: normal
stage: needs patch
status: open
title: test_ssl failure
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:47:30 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 22:47:30 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255560450.67.0.128968211077.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

Summary of your points with my responses :


> 1) it doesn't exist in any other implementation that I know;

That's exactly why I proposed to discuss it with the developers of other 
implementations (I cited PCRE, Perl and PHP developers, there are 
others).


> 2) if implemented as default behavior:
>   * it won't be backward-compatible;

Wrong. This does not even change the syntax of regualr expressions 
themselves.

>   * it will increase the complexity;

Wrong. All the mechanic is already implemented: when the parser will 
store string index positions for a matched group it will just have to 
append a pair in the list stored in MatchObject.group(index) (it will 
create the list if it is not ealready there, but it should be already 
initialized to an empty list by the compiler) when the flag.R is set, 
instead of overwriting the existing pair without wondering if there was 
already another occurence of the same capturing group.


> 3) it will be a proprietary extension and it will reduce the
compatibility with other implementations;

Already suggested above. This will hovever NOT affect the compatibility 
of existing implementation that don't have the R flag.


> 4) I can't think to any real word situation where this would be really
useful.

There are really a lot ! Using multiple split operations and multiple 
parsing on partly parsed regular expressions will not be a solution in 
many situations (think about how you would perform matches and using 
them that in 'vi' or 'ed' with a single "s/regexp/replacement/flag" 
instruction, if there's no extension with a flag and a syntax for 
accesing the individual elements the replacement string).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:53:00 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 22:53:00 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255560780.1.0.272042029047.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

And anyway, my suggestion is certainly much more useful than atomic groups 
and possessive groups that have much lower use, and which are already 
being tested in Perl but that Python (or PCRE, PHP, and most 
implementations of 'vi'/'ed', or 'sed') still does not support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:53:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 22:53:38 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255560818.03.0.643211846377.issue7132@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you read what Ezio wrote carefully you will see that he addressed
both of your points: he acknowledged that a flag would solve (2) (but
disagreed that it was worth it), and he said you could use the first
expression to validate the string before using the split to obtain the
data.  Doing it all in one regex might seem more efficient, but at least
in the single use case you have presented it would lead to more
complicated code.

Simple. obvious feature requests can be opened and acted upon directly
in the tracker, but more complicated requests should be made as
proposals on the python-ideas list, and if they are well received there
then an issue can be opened (or in this case you could reopen this one)
in the tracker with a pointer to the python-ideas thread.  In most
cases, such an issue would need to include a proposed patch.

Note that we don't really have a resolution that says 'sent to
python-ideas', thus the use of the 'rejected' status.

----------
nosy: +r.david.murray
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:55:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2009 22:55:02 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255560902.31.0.322024687782.issue7133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a possible patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15130/ssl_newbuf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:00:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2009 23:00:24 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255561224.07.0.23104515285.issue7132@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just to clarify, when I said "in most cases such an issue would need to
include a proposed patch", I mean that even if everyone agrees it is a
good idea it isn't likely to happen unless there is a proposed patch :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:26:59 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 23:26:59 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255562819.18.0.953967906207.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

I had read carefully ALL what ezio said, this is clear in the fact that 
I have summarized my responses to ALL the 4 points given by ezio.

Capturing groups is a VERY useful feature of regular expressions, but 
they currently DON'T work as expected (in a useful way) when they are 
used within repetitions (unless you don't need any captures at all, for 
example when just using find(), and not performing substitutions on the 
groups.

My proposal woul have absolutely NO performance impact when capturing 
groups are not used (find only, without replacement, so there the R flag 
can be safely ignored).

It would also not affect the case where capturing groups are used in the 
regexp, but these groups are not referenced in the substitution or in 
the code using MatchObject.group(index) : these indexes are already not 
used (or should not, because this is most of the time a bug when it just 
returns the last occurence).

Using multiple parsing operations with multiple regexps is really 
tricky, when all could be done directly from the original regexp, 
without modifying it. In addition, using split() or similar will not 
work as expected, when the splitting operations will not correctly parse 
the context in which the multiple occurences are safely separated (this 
context is only correctly specified in the original regexp where the 
groups, capturing or not, are specified).

This extension will also NOT affect the non-capturing groups like:
 (?:X){m,n}
 (?:X)*
 (?:X)+
It will ONLY affect the CAPTURING groups like:
 (X){m,n}
 (X)*
 (X)+
and only if the R flag is set (in which case this will NOT affect the 
backtracking behavior, or which strings that will be effectively 
matched, but only the values of the returned "\n" indexed group.

If my suggestion to keep the existing MatchObject.function(index) API 
looks too dangerous for you, because it would change the type of the 
returned values when the R flag is set, you can as well rename them to 
get a specific occurence of a group. Such as:

 MatchObject.groupOccurences(index)
 MatchObject.startOccurences(index)
 MatchObject.endOccurences(index)
 MatchObject.spanOccurences(index)
 MatchObject.groupsOccurences(index)

But I don't think this is necessary; it will be already expected that 
they will return lists of values (or lists of pairs), instead of just 
single values (or single pairs) for each group: Python (as well as PHP 
or Perl) can already manage return values with varying datatypes.

May be only PCRE (written for C/C++) would need a new API name to return 
lists of values instead of single values for each group, due to existing 
datatype restrictions.

My proposal is not inconsistant: it returns consistant datatypes when 
the R flag is set, for ALL capturing groups (not just those that are 
repeated.

Anyway I'll submit my idea to other groups, if I can find where to post 
them. Note that I've already implemented it in my own local 
implementation of PCRE, and this works perfectly with effectively very 
few changes (currently I have had to change the datatypes for matching 
objects so that they can return varying types), and I have used it to 
create a modified version of 'sed' to perform massive filtering of data:

It really reduces the number of transformation steps needed to process 
such data correctly, because a single regexp (exactly the same that is 
already used in the first step used to match the substrings we are 
interested in, when using existing 'sed' implementations) can be used to 
perform the substitutions using indexes within captured groups. And I 
would like to have it incoporated in Python (and also Perl or PHP) as 
well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:28:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Oct 2009 23:28:32 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255562912.36.0.0208341925607.issue7132@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> You're wrong, it WILL be compatible, because it is only conditioned
> by a FLAG.

Sorry, I missed that you mentioned the flag already in the first
message, but what I said in 1), 3) and 4) is still valid.

> There are plenty of other more complex cases for which we really
> need to capture the multiple occurences of a capturing group within
> a repetition.

Can you provide some example where your solution is better than the
other available way of doing it? During the years lot of extensions have
been added to the regex engines, if no one added this is probably
because these problems can be already solved in other ways.

> I'm NOT asking you how to parse it using MULTIPLE regexps and
> functions. 
> Of course you can, but this is a distinct problem, but certinaly NOT
> a general solution (your solution using split() will NOT work with
> really A LOT of other regular expressions).

Even with your solution, in most of the cases you will need additional
steps to assemble the results (at least in the cases with some kind of
separator, where you have to join the first element with the followings).

I can see a very limited set of hypothetical corner cases where your
proposal may save a few line of codes but I don't think it's worth
implementing all this just for them.
An example could be:
>>> re.match('^([0-9A-F]{2}){4} ([a-z]\d){5}$', '3FB52A0C a2c4g3k9d3',
re.R).groups()
(['3F', 'B5', '2A', '0C'], ['a2', 'c4', 'g3', 'k9', 'd3'])
but it's not really a real-world case, if you have some real-world
example I'd like to see it.

> In addition, your suggested regexp for IPv4:
> '^(\d{1,3})(?:\.(\d{1,3})){3}$'
> is completely WRONG !

That's why I wrote 'without checking if they are in range(256)'; the
fact that this regex matches invalid digits was not relevant in my
example (and it's usually easier to convert the digits to int and check
if 0 <= digits <= 255). :)


>> 1) it doesn't exist in any other implementation that I know;
>
> That's exactly why I proposed to discuss it with the developers of
> other implementations (I cited PCRE, Perl and PHP developers, there
> are others).

So maybe this is not the right place to ask.

>> 3) it will be a proprietary extension and it will reduce the
>> compatibility with other implementations;
>
> Already suggested above. This will hovever NOT affect the
> compatibility of existing implementation that don't have the R flag.

What I meant is that a regex that uses the re.R flag in Python won't
work in other languages/implementations because they don't have it, and
a "general" regex (e.g. for an ipv6 address) will have to be
adapted/rewritten in order to take advantage of re.R.

>> 4) I can't think to any real word situation where this would be 
>> really useful.
>
> There are really a lot ! Using multiple split operations and multiple 
> parsing on partly parsed regular expressions will not be a solution 
> in many situations (think about how you would perform matches and 
> using  them that in 'vi' or 'ed' with a single
> "s/regexp/replacement/flag" instruction, if there's no extension
> with a flag and a syntax for accesing the individual elements the 
> replacement string).

Usually when the text to be parsed starts to be too complex is better to
use another approach, e.g. using a real parser or dividing the text in
smaller units and work on them independently. Even if re.R could make
this easier I would still prefer to have a few more line of code that do
different things that a single big regex that does everything.

> And anyway, my suggestion is certainly much more useful than atomic 
> groups and possessive groups that have much lower use [...]

Then why no one implemented it yet? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:40:04 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 14 Oct 2009 23:40:04 +0000
Subject: [issue7134] Add looping capability to regrtest
In-Reply-To: <1255563604.05.0.373635467839.issue7134@psf.upfronthosting.co.za>
Message-ID: <1255563604.05.0.373635467839.issue7134@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

We should add "loop this test" capabilities to regrtest - running tests in 
a tight loop can help debug issues which don't appear with a one-off run.

See:
http://mail.python.org/pipermail/python-dev/2009-June/090238.html

----------
assignee: jnoller
components: Tests
messages: 94052
nosy: jnoller
priority: normal
severity: normal
status: open
title: Add looping capability to regrtest
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7134>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:40:56 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Oct 2009 23:40:56 +0000
Subject: [issue7134] Add looping capability to regrtest
In-Reply-To: <1255563604.05.0.373635467839.issue7134@psf.upfronthosting.co.za>
Message-ID: <1255563656.83.0.36797956533.issue7134@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7134>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:44:02 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 23:44:02 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255563842.89.0.44976557928.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

ezio said:
>>> re.match('^(\d{1,3})(?:\.(\d{1,3})){3}$', '192.168.0.1').groups()
('192', '1')
> If I understood correctly what you are proposing, you would like it to
return (['192'], ['168', '0', '1']) instead.

Yes, exactly ! That's the correct answer that should be returned, when 
the R flag is set.

> This will also require an additional step to join the two lists to get 
the list with the 4 values.

Yes, but this is necessary for full consistency of the group indexes. 
The current return value is clearly inconsistant (generally it returns 
the last occurence of the capturing group, but I've discovered that this 
is not always the case, because of matches that are returned after 
backtracking...)

It is then assumed that when the R flag is set, ALL occurences of 
repeated groups will be returned individually, instead of just a 
'random' one. Note that for full generalization of the concept, there 
should even be lists of lists if a capturing group contains itself 
another inner capturing group (with its own index), in order to 
associate them correctly with each occurence of the outer capturing 
group (however I've still not experimented this in my local 
experimentation, so all occurences are grouped in the same returned 
list, independantly of the occurence of the outer capturing group in 
which they were found).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:44:26 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 14 Oct 2009 23:44:26 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255563866.46.0.888739761608.issue7120@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

>The addition of multiprocessing support to logging seems to have 
happened 
> in 2.6.2; bad timing for a feature. :-(

Just in minor self-defense, this wasn't a feature, it was a bug fix. The 
original multiprocessing code base relied on some unfortunate monkey-
patching of the logging module to insert itself into the logging module. 
That code was broken in the merge into 2.6, and I didn't catch it. So, I 
felt this was a bug fix, and not a feature-add.

I apologize for this.

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:49:32 2009
From: report at bugs.python.org (Andi Welch)
Date: Wed, 14 Oct 2009 23:49:32 +0000
Subject: [issue7135] AttributeError: 'module' object has no attribute
	'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>


New submission from Andi Welch <andiwelch at gmail.com>:

I received a working script created with Active Python 2.6.2 for 
Windows 32 bit.  I downloaded the Active Python 64 bit Windows version 
for my 64 bit Windows Vista OS and have attempted to run the script.  I 
get the following error:

Traceback (most recent call last):
File "ofx-ba-tfb-auto.py", line 212, in
client.doQuery(query, argv[1]+"_acct.ofx")
File "ofx-ba-tfb-auto.py", line 178, in doQuery
h = httplib.HTTPSConnection(host)
AttributeError: 'module' object has no attribute 'HTTPSConnection'

I see a few references (not on this site) to the error, but none seem 
to fit exactly and being a Python novice I wasn't sure what direction 
to turn.  Most suggest that my Python installation is missing a needed 
library to support SSL.  I also tried using the 2.6.3.7 version of 
Active Python for WIN 64 and get the same exact error. 

Would appreciate any and all assistance.  Thank you.

----------
components: Library (Lib)
messages: 94055
nosy: awelch
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'HTTPSConnection'
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:52:12 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Wed, 14 Oct 2009 23:52:12 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255564332.2.0.666768205065.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

> That's why I wrote 'without checking if they are in range(256)'; the
fact that this regex matches invalid digits was not relevant in my
example (and it's usually easier to convert the digits to int and check
if 0 <= digits <= 255). :)

NO ! You have to check also the number of digits for values below 100 (2 
digits only) or below 10 (1 digit only)

And when processing web log files for example, or when parsing Wiki 
pages or emails in which you want to autodetect the presence of ONLY 
valid IP addresses within some contexts, where you want to transform 
them to another form (for example when converting them to links or to 
differentiate 'anonymous' users in wiki pages from registered named 
users, you need to correctly match these IP addresses. In addition, 
these files will often contain many other occurences that you don't want 
to transform, but just some of them in specific contexts given by the 
regexp. for this reason, your suggestion will often not work as 
expected.

The real need is to match things exactly, within their context, and 
capturing all occurences of capturing groups.

I gave the IPv4 regexp only as a simple example to show the need, but 
there are of course much more complex cases, and that's exactly for 
those cases that I would like the extension: using alternate code with 
partial matches and extra split() operations give a code that becomes 
tricky, and most often bogous. Only the original regexp is precise 
enough to parse the content correctly, find only the matches we want, 
and capturing all the groups that we really want, in a single operation, 
and with a near-zero cost (and without complication in the rest of the 
code using it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:54:01 2009
From: report at bugs.python.org (A Welch)
Date: Wed, 14 Oct 2009 23:54:01 +0000
Subject: [issue7135] AttributeError: 'module' object has no attribute
	'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255564441.83.0.181189725505.issue7135@psf.upfronthosting.co.za>


Changes by A Welch <andiwelch at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:00:20 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 00:00:20 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255564820.07.0.807722762004.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

> Even with your solution, in most of the cases you will need additional
steps to assemble the results (at least in the cases with some kind of
separator, where you have to join the first element with the 
followings).

Yes, but this step is trivial and fully predictable. Much more viable 
than the other solutions proposed which gives tricky and often complex 
and bogous code.

How many bugs have been found in code using split() for example to parse 
URLs ? There are countlesss in many softwares (and it is not terminated 
!)

And in fine, the only solution is to simply rewrite the parser 
completely, without regexps at all, or to reduce the generality of the 
problems that the program was supposed to solve (i.e. asserting in the 
code some implementation limits, to reject some forms that were 
previously considered valid). Think about it, the capturing groups are 
the perfect solution for solving the problem cleanly, provided that they 
work as intended and return all their occurences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:13:59 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 00:13:59 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255565639.68.0.980406007472.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

> a "general" regex (e.g. for an ipv6 address)

I know this problem, and I have already written about this. It is not 
possible to parse it in a single regexp if it is written without using 
repetitions. But in that case, the regexp becomes really HUGE, and the 
number of groups in the returned match object is prohibitive. That's why 
CPAN has had to write a specific module for IPv6 addresses in Perl.

Such module can be reduced to just a couple of lines with a single 
regexp, if its capturing groups correctly return ALL their occurences in 
the regexp engine: it requires no further processing and analysis, and 
the data can effectively be reassembled cleanly, just from the returned 
groups (as lists):
- \1 and \2 (for hex components of IPv6 in hex format only, where \1 can 
occur 0 or 1 time, and \2 can occur 0 to 7 times)
- or from \1 to \2 and \3 to \4 (for hex components in \1..\2, where \1 
occurs 0 or 1 time and \2 occurs 0 to 5 times, and for decimal 
components in \3..\4, where \3 occurs 1 time and \4 occurs exactly 3 
times).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:19:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2009 00:19:02 +0000
Subject: [issue7135] AttributeError: 'module' object has no attribute
	'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255565942.77.0.47168146017.issue7135@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The httplib module creates the HTTPSConnection class only if it can
successfully import the ssl module.  So your installation must be
missing that module.  Since you say your are using an ActivePython
version, you should contact their community for support, since
presumably the problem is in the ActivePython installation somewhere.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:22:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2009 00:22:40 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255566160.4.0.573588465445.issue7132@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:26:56 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 00:26:56 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255566416.16.0.833186659301.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

>> And anyway, my suggestion is certainly much more useful than atomic 
>> groups and possessive groups that have much lower use [...]
>Then why no one implemented it yet? :)

That's because they had to use something else than regexps to do their 
parsing. All those that had to do that *pested* that the regexps were 
not capturing all occurences.

And then later they regretted it, because they had to fix their 
alternate code (such as those using the bogous split() alternatives...) 
and finally rewrote their own parsers (sometimes with a combination of 
(f)lex+yacc/bison, even if the full expression was given in a single 
regexp which was expressive enough to match only the exact match they 
wanted, but without using the returned captured groups): this means an 
extra parsing for the found substring (in their correct context) in 
order to process it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:30:44 2009
From: report at bugs.python.org (A Welch)
Date: Thu, 15 Oct 2009 00:30:44 +0000
Subject: [issue7135] AttributeError: 'module' object has no attribute
	'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255566644.07.0.670220737275.issue7135@psf.upfronthosting.co.za>


A Welch <andiwelch at gmail.com> added the comment:

Thank you for your response and my apologies for posting this in the 
incorrect support forum.  I thought that this forum was for all the 
various versions of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:33:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2009 00:33:34 +0000
Subject: [issue7135] AttributeError: 'module' object has no attribute
	'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255566814.5.0.703487023566.issue7135@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

An understandable confusion, but no, python.org just maintains the
original version, called CPython or python.org Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:35:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2009 00:35:01 +0000
Subject: [issue7135] AttributeError: 'module' object has no attribute
	'HTTPSConnection'
In-Reply-To: <1255564172.76.0.168636291219.issue7135@psf.upfronthosting.co.za>
Message-ID: <1255566901.13.0.0637896215501.issue7135@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I should clarify a little:  ActivePython a _distribution_ of CPython,
one not maintained by python.org.  Then there are other versions, such
as IronPython, and Jython....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7135>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:40:44 2009
From: report at bugs.python.org (Toby Donaldson)
Date: Thu, 15 Oct 2009 00:40:44 +0000
Subject: [issue7136] Idle File Menu Option Improvement
In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za>
Message-ID: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za>


New submission from Toby Donaldson <tjdonaldson at gmail.com>:

I've been using Idle to teach beginning programming to university
students for the last 6 or 7 years. I've taught hundreds and hundreds of
students, and the single biggest confusion with Idle is this:

"New Window" in the file menu is ambiguous

Proposed fix: change "New Window" to "New File", or "New Program"

Many beginners don't get the difference between a shell window and
program window. I spend some time explaining the difference, and yet
they see "New Window" and don't know if this means a shell window or
program window.

Obviously this is not an issue for non-beginners, or even for anyone
willing to experiment for a minute or two, but it seems to me this is a
small change that could be useful to beginners. 

Plus more precise menu options are usually a good thing in general.

----------
components: IDLE
messages: 94064
nosy: tjd
severity: normal
status: open
title: Idle File Menu Option Improvement
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7136>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:45:30 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 00:45:30 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255567530.46.0.269372546886.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

>>> re.match('^(\d{1,3})(?:\.(\d{1,3})){3}$', '192.168.0.1').groups()
('192', '1')
> If I understood correctly what you are proposing, you would like it to
return (['192'], ['168', '0', '1']) instead.

In fact it can be assembled in a single array directly in the regexp, by 
naming the destination capturing group (with the same name, it would get 
the same group index, instead of of allocating a new one). E.g., with 
someting like:

>>> re.match('^(?P<parts>=\d{1,3})(?:\.(?P<parts>=\d{1,3})){3}$', 
'192.168.0.1').groups()

would return ("parts": ['192', '168', '0', '1']) in the same first 
group.

This could be used as well in PHP (which supports associative arrays for 
named groups which are also indexed positionnaly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:50:33 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 15 Oct 2009 00:50:33 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255567833.82.0.258927839492.issue7132@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Instead of a new flag, a '*' could be put after the quantifier, eg:

    (\d+)(?:\.(\d+)){3}*

MatchObject.group(1) would be a string and MatchObject.group(2) would be
a list of strings.

The group references could be \g<1>, \g<2:0>, \g<2:1>, \g<2:2>.

However, I think that it's extending regexes too far; something else
should be used, eg pyparsing or some type of context-free grammar with
optional constraints.

-1 from me

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 04:04:32 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 02:04:32 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255572272.31.0.461686838955.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

You said that this extension was not implemented anywhere, and you were 
wrong.

I've found that it IS implemented in Perl 6! Look at this discussion:

http://www.perlmonks.org/?node_id=602361

Look at how the matches in quantified capture groups are returned as 
arrayref's (i.e. references to a numbered array).

So my idea is not stupid. Given that Perl rules the world of the Regexp 
language, it will be implemented elsewhere sonner or later, notably in 
PCRE, awk, vi, sed, PHP, .NET library...

Already, this is used in CPAN libraries for Perl v6... (when the X flag 
is set for extensions)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 04:41:19 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 02:41:19 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255574479.64.0.0316658450485.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

Anyway, there are ways to speedup regexps, even without instructing the 
regexps with anti-backtracking syntaxes.

See http://swtch.com/~rsc/regexp/regexp1.html
(article dated January 2007)
Which discusses how Perl, PCRE (and PHP), Python, Java, Ruby, .NET 
library... are slow because they are using backtracking a single state 
in the NFA, instead of using simultaneously active states (which 
correctly emulates the DFA, without having to actually build the DFA 
transition states table, which could grow combinatorially, as seen in 
yacc and Bison).

Java uses now the Thomson approach in its latest releases, but I wonder 
how Python works: does it use the DFA simulation? Do you use PCRE?

Note that I've been using the DFA simulation since more than 20 years in 
1987, when I built my first regexp matcher (because the existing 
implementation at that time were really damn slow), after I read the 
Aho/Sethi/Ullman book which already demonstrated the algorithm.

This algorithm has been implemented in some tools replacing the old 
yacc/Bison tools, because they generate huge DFA transition tables (and 
this was the reason why Lex and Yacc were maintained as separate tools, 
Lex using the single-state NFA approach with excessive backtracking, and 
Yacc/Bison trying to generate the full DFA transition tables.) : the 
first language to use this approach was the Purdue Univerity Compiler 
Construction Tools Set (PCCTS) which was initially written in C and is 
now fully written and supported in Java.

The Perl 6 extension for quantified capturing groups will have a slow 
adoption, as long as Perl will continue the slow single-state NFA 
approach with excessive backtracking, instead of the Aho/Sethi/Ullman 
(ASU) approach (that some are attributing to Thomson due to the article 
in 2007, but this is false) using simultaneously active states. But 
anyway, it already exists (and Perl developers are already working on 
rewriting the engine using the ASU approach).

But my suggstion is much more general, as it should not just apply to 
quantified capturing groups, but to any capturing group that is part of 
a subexpression which is quantified.

And the way I specified it, it does not depend on the way the engine is 
written (whever it uses a single-state NFA or multi-state NFA or 
generates and uses a DFA transition state with single-state like in 
Yacc/Bison), because capturing groups are just used to store position 
pairs, and regexp engines already have to count them for effectively 
matching the greedy or non-greedy quantifiers, so this immediately 
provides a usable index for storing at successive positions in a 
numbered array for captured groups.

The simple test case is effectively to try to match /(aa?)*a+/ with 
strings longer than a few dozens of 'a'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 05:07:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Oct 2009 03:07:37 +0000
Subject: [issue7069] inspect.isabstract to return boolean values only
In-Reply-To: <1254803562.64.0.0318386285546.issue7069@psf.upfronthosting.co.za>
Message-ID: <1255576057.39.0.420227697645.issue7069@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r75433.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7069>
_______________________________________

From report at bugs.python.org  Thu Oct 15 05:25:56 2009
From: report at bugs.python.org (Yang Zhang)
Date: Thu, 15 Oct 2009 03:25:56 +0000
Subject: [issue7137] Socket documentation not updated
In-Reply-To: <1255577156.35.0.86012229105.issue7137@psf.upfronthosting.co.za>
Message-ID: <1255577156.35.0.86012229105.issue7137@psf.upfronthosting.co.za>


New submission from Yang Zhang <yaaang at gmail.com>:

e.g., the doc still says socket.makefile([mode[, bufsize]]), which aren't 
the actual python3 params.

----------
assignee: georg.brandl
components: Documentation
messages: 94070
nosy: georg.brandl, yang
severity: normal
status: open
title: Socket documentation not updated
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7137>
_______________________________________

From report at bugs.python.org  Thu Oct 15 05:28:20 2009
From: report at bugs.python.org (Yang Zhang)
Date: Thu, 15 Oct 2009 03:28:20 +0000
Subject: [issue7137] Socket documentation not updated
In-Reply-To: <1255577156.35.0.86012229105.issue7137@psf.upfronthosting.co.za>
Message-ID: <1255577300.36.0.169735222778.issue7137@psf.upfronthosting.co.za>


Changes by Yang Zhang <yaaang at gmail.com>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7137>
_______________________________________

From report at bugs.python.org  Thu Oct 15 05:37:15 2009
From: report at bugs.python.org (Philippe Verdy)
Date: Thu, 15 Oct 2009 03:37:15 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1255577835.82.0.0456978065129.issue7132@psf.upfronthosting.co.za>


Philippe Verdy <verdy_p at wanadoo.fr> added the comment:

Umm.... I saif that the attribution to Thompson was wrong, in fact it 
was correct. Thompson designed and documented the algorithm in 1968, 
long before the Aho/Seti/Ullman green book... so the algorithm is more 
than 40 years old, and still not in Python, Perl and PCRE (but it is 
present in GNU awk...)

The paper published in swtch.com is effectively written in 2007, but its 
conclusions are perfectly valid. The interesting aspect of this paper is 
that it demonstrates that the Thompson's multi-state NFA approach is 
still the best one, and better than what Perl, PCRE (and PHP), Python, 
Ruby and others are using, but that it can be also optimized further by 
caching the DFA construction "on the fly" (see the blue curve on the 
displayed diagram) while parsing the the already precompiled multi-state 
NFA.

The cache for DFA states will fill up while matching the regexp against 
actual strings, so it will be much faster (and much less memory-and-
time-greedy than generating the full DFA transition table at compilation 
time like in Bison/Yacc).

However the paper still does not discusses how to make the DFA states 
cache limited in size. Notably because the longer the input text will 
be, the more the DFA cache will contain DFA states. One simple rule is 
to limit the number of cached DFA states, and then to allow all stored 
transitions to go all multiple-states in the NFA, and optionally to a 
single DFA state in the cache.

Then the DFA cache can be used in a LIFO manner, to purge it 
automatically from unused states, in order to reuse them (for caching 
another new DFA state which is still not present in the cache, when the 
cache has reached its maximum size): if this occurs, the other existing 
DFA states that point to it must be cleaned (their DFA state pointer or 
reference, stored in their NFA or DFA transitions, must be cleared/set 
to null, so that they will only contain the list of pointers to outgoing 
NFA states). The problem is how to look for a multistate in the DFA 
cache: this requires some fast lookup, but this can be implemented in a 
fast way using hash tables (by hashing the list of NFA states 
represented in the DFA state).

Apparently, GNU awk does not use the cached DFA approach: it just uses 
the NFA directly when the input text is lower than two dozens of 
characters, then it builds the full DFA as soon as the input text 
becomes larger (this explains the sudden, but moderate increase of 
time). But I've seen that GNU awk has the defect of this unlimited DFA 
generation approach: its excessive use of memory when the input text 
increases, because the number of DFA states added to the cache is 
contantly growing with the input, and the time to match each characer 
from the input slowly increases too. At some point, it will crash and 
exit due to memory limits exhaustion, when no more DFA states can be 
stored. That's why the DFA cache MUST be maintained under some level.

I'll try to implement this newer approach first in Java (just because I 
better know this language than Python, and beacause I think it is more 
solid in terms of type-safety, so it can reduce the number of bugs to 
correct before getting something stable).

In Java, there's a clean way to automatically cleanup objects from 
collections, when they are no longer needed: you just need to use weak 
references (the garbage collector will automatically cleanup the older 
objects, when needed). But this approach is not easy to port, and in 
fact, if it can effectively solve some problems, it will still not 
forbif the cache to use up to the maximum VM size. for performance 
reasons, I see little interest in storing more than about 1 million DFA 
states in the cache (also because the hash table that would be used 
would be less efficient when looking up for the key of a NFA multi-state 
where the DFA state is stored). So I will probably not use weak 
references, but will first use a maximum size (even if weak references 
could help maintain the cache at even lower bounds than the allowed 
maximum, if VM memory size is more constrained: it is a good idea in all 
Java programs to allow caches introduced only for performance reasons to 
also collaborate with the garbage collector, in order to avoid the 
explosion of all caches used in various programs or libraries). I don't 
know if Python supports the concept of weak references for handling 
performance caches.

May be I'll port it later in Python, but don't expect that I'll port it 
to C/C++ (as a replacement of PCRE), because I now hate these unsafe 
languages despite I have practiced them for many years: others would do 
that for me, when I'll have published my Java implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Oct 15 06:18:41 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Oct 2009 04:18:41 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1255580321.01.0.160907185597.issue7057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is an incomplete patch. I fixed all the markup errors, typos and
similar issues you mentioned and a few more that I noticed.

Someone that knows Tkinter better than me should take care of the
remaining issues, i.e.:
 * is Xlib still used?
 * bmp files on Windows
 * the section about Canvas

3.x specific issues:

1. In most of the places I think it's OK to use 'Tkinter' and use
:mod:`tkinter` only when referring specifically to the module. I also
fixed other :mod:`Tkinter` around in the Doc.

2. Both fixed.

3. Fixed. I also changed *tkinter* to :mod:`tkinter`. I don't know about
Xlib.

Not 3.x specific:

> 10. "Specifically, the man pages in the mann directory are most 
> useful."
> Is 'mann' literally correct? a typo? or meant to mean 'man#', where # 
> is a digit?

I used 'manN' and added the link you provided (even if right now the
site seems down so I can't verify if it's correct).

> 11. "Credits:
> Tkinter was written by Steen Lumholt and Guido van Rossum. 
> Tk was written by John Ousterhout while at Berkeley. "
> Except for the first two lines, the entries are in historical order, 
> so I would reverse the first two.
 
Done.

> 12. 24.1.6.6. Tk Option Data Types
> "To specify an X bitmap filename, give the full path to the file,
> preceded with an @, as in "@/usr/contrib/bitmap/gumby.bit"."
> *nix only? what about windows .bmp file?

Does someone know the answer?

> 13. (ttk section) 24.2.3.1. Standard Options
> "0, 1 or an empty is return." => "0, 1 or an empty string is 
> returned."

Fixed.

> PS. I like the colors of the option-description tables.

Thank Raymond for them.

----------
keywords: +patch
Added file: http://bugs.python.org/file15131/issue7057.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Thu Oct 15 06:26:02 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 15 Oct 2009 04:26:02 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255580762.17.0.196544383653.issue7120@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy: +barry
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Thu Oct 15 07:37:32 2009
From: report at bugs.python.org (Ryan Williams)
Date: Thu, 15 Oct 2009 05:37:32 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>


New submission from Ryan Williams <rdw at lindenlab.com>:

This crash is surprisingly consistent across versions, operating
systems, and whether the c module is used or not:

Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.cElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.5.4 (r254:67916, Jun  3 2009, 14:22:10) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.4.4 (#2, Oct 22 2008, 20:20:22) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from elementtree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.5 (release25-maint, Jul 23 2008, 18:15:29) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

I'm a little fuzzy on who's responsible for elementtree, so if there's a
more appropriate venue to file this bug, please let me know.

----------
components: Library (Lib)
messages: 94073
nosy: whichlinden
severity: normal
status: open
title: elementtree segfaults on invalid xml declaration
type: crash
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 08:21:30 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 15 Oct 2009 06:21:30 +0000
Subject: [issue7139] Incorrect serialization of end-of-line characters in
	attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>


New submission from Moriyoshi Koizumi <mozo+python at mozo.jp>:

ElementTree doesn't correctly serialize end-of-line characters (#xa, 
#xd) in attribute values.  Since bare end-of-line characters are 
converted to #x20 by the parser according to the specification [1], such 
characters that are represented as character references in the original 
document must be serialized in the same form.

[1] http://www.w3.org/TR/xml11/#AVNormalize   

### sample code

from xml.etree.ElementTree import ElementTree
from cStringIO import StringIO

# builder = ElementTree(file=StringIO("<foo>\x0d</foo>"))
# out = StringIO()
# builder.write(out)
# print out.getvalue()

out = StringIO()
ElementTree(file=StringIO(
'''<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE foo [
<!ELEMENT foo (#PCDATA)>
<!ATTLIST foo attr CDATA "">
]>
<foo attr="   test
&#13;test&#32; test&#10;a  ">&#10;</foo>
''')).write(out)
# should be "<foo attr="   test &#13;test  test&#10;a  ">\x0a</foo>
print out.getvalue()

out = StringIO()
ElementTree(file=StringIO(
'''<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE foo [
<!ELEMENT foo (#PCDATA)>
<!ATTLIST foo attr NMTOKENS "">
]>
<foo attr="   test
&#13;test&#32; test&#10;a  ">&#10;</foo>
''')).write(out)
# should be "<foo attr="test &#13;test test&#10;a">\x0a</foo>
print out.getvalue()

----------
components: XML
messages: 94074
nosy: moriyoshi
severity: normal
status: open
title: Incorrect serialization of end-of-line characters in attribute values
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7139>
_______________________________________

From report at bugs.python.org  Thu Oct 15 08:21:42 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 15 Oct 2009 06:21:42 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1255587702.98.0.576112543722.issue7139@psf.upfronthosting.co.za>


Changes by Moriyoshi Koizumi <mozo+python at mozo.jp>:


----------
title: Incorrect serialization of end-of-line characters in attribute values -> ElementTree: Incorrect serialization of end-of-line characters in attribute values

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7139>
_______________________________________

From report at bugs.python.org  Thu Oct 15 08:26:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Oct 2009 06:26:58 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255588018.73.0.00422010727254.issue7138@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Confirmed on 3.1 on Windows too.

----------
assignee:  -> effbot
nosy: +effbot, ezio.melotti
priority:  -> high
versions: +Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 08:28:06 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Oct 2009 06:28:06 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1255588086.8.0.0638032572829.issue7139@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> effbot
nosy: +effbot
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7139>
_______________________________________

From report at bugs.python.org  Thu Oct 15 08:36:33 2009
From: report at bugs.python.org (chuck)
Date: Thu, 15 Oct 2009 06:36:33 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255588593.67.0.156108688322.issue7138@psf.upfronthosting.co.za>


chuck <jan.hosang at gmail.com> added the comment:

I'm seeing this on the built-in python on os x 10.6, too:
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin


But neither with the trunk
Python 2.7a0 (trunk:75433M, Oct 15 2009, 08:27:13) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

nor with a ports installation
Python 2.6.3 (r263:75183, Oct  7 2009, 07:05:03) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

----------
nosy: +chuck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 09:39:06 2009
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Thu, 15 Oct 2009 07:39:06 +0000
Subject: [issue7139] ElementTree: Incorrect serialization of end-of-line
	characters in attribute values
In-Reply-To: <1255587690.83.0.0369111720877.issue7139@psf.upfronthosting.co.za>
Message-ID: <1255592346.24.0.605999715955.issue7139@psf.upfronthosting.co.za>


Moriyoshi Koizumi <mozo+python at mozo.jp> added the comment:

Tabs must be converted to character references as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7139>
_______________________________________

From report at bugs.python.org  Thu Oct 15 10:23:22 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 15 Oct 2009 08:23:22 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1255595002.13.0.98639689054.issue5243@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

It looks like there's a missing part in the patch: get_outputs(), and
get_inputs() should also return files created in build()

Now something I don't understand is how reportlab distribution is doing
to copy the compiled extensions when "install" is called.

Could you point me please to the package so I can test that ?

Thanks !

----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 3.0, Python 3.2 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Thu Oct 15 10:55:11 2009
From: report at bugs.python.org (egreen)
Date: Thu, 15 Oct 2009 08:55:11 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255596911.52.0.813251540647.issue7080@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

Could someone triage this?  And review my simple fix?  I think it should
be a release blocker.

It seems to me to be a problem on all 64-bit non-Windows platforms, or
any platform if using UCS-4.  The 4 high-order bytes of an 8-byte
Py_ssize_t variable are not initialized.

Thanks.

----------
components: +Extension Modules -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Thu Oct 15 11:58:24 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 15 Oct 2009 09:58:24 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255600704.56.0.758581293227.issue7138@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Here is a stacktrace of the crash with the system Python 2.6.1 on Mac OS
X 10.6.1:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000101000000
0x00007fff810f96b8 in XML_SetEncoding ()
(gdb) bt
#0  0x00007fff810f96b8 in XML_SetEncoding ()
#1  0x00007fff810ecad0 in XML_GetCurrentLineNumber ()
#2  0x00000001005c2150 in initpyexpat ()
#3  0x00000001005c3516 in initpyexpat ()
#4  0x00000001000891df in PyEval_EvalFrameEx ()
#5  0x0000000100089330 in PyEval_EvalFrameEx ()
#6  0x0000000100089330 in PyEval_EvalFrameEx ()
#7  0x000000010008accf in PyEval_EvalCodeEx ()
#8  0x000000010008ad62 in PyEval_EvalCode ()
#9  0x00000001000a265a in Py_CompileString ()
#10 0x00000001000a44dd in PyRun_InteractiveOneFlags ()
#11 0x00000001000a4615 in PyRun_InteractiveLoopFlags ()
#12 0x00000001000a4685 in PyRun_AnyFileExFlags ()
#13 0x00000001000b0286 in Py_Main ()
#14 0x0000000100000e6c in ?? ()

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 12:00:19 2009
From: report at bugs.python.org (Peter Saunders)
Date: Thu, 15 Oct 2009 10:00:19 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1255600819.69.0.701453736073.issue7123@psf.upfronthosting.co.za>


Peter Saunders <pajs at fodder.org.uk> added the comment:

Tested on Linux, and repeated the issue - just to confirm this isn't a
Solaris specific issue.

Tested using dummy_threading - bug does not appear when that is used.

Added _verbose=True to threads, and log_to_stderr(SUBDEBUG) set for Process.

Attached is the output of the script with those set. 

Other odd things to notice, and some point, more than 2 children
sometimes exist.. 

isalive PID: 7646 : True
isalive PID: 7652 : True
isalive PID: 7653 : True
isalive PID: 7646 : True
isalive PID: 7652 : True
isalive PID: 7653 : True
isalive PID: 7646 : True
isalive PID: 7653 : True

The code starts 2 threads, which start 2 processes. Both threads are
joined before new ones are started.. So, in theroy, only 2 should be
able to exist at once.. ?

----------
Added file: http://bugs.python.org/file15132/results1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7123>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:24:52 2009
From: report at bugs.python.org (Jamie Kirkpatrick)
Date: Thu, 15 Oct 2009 11:24:52 +0000
Subject: [issue7140] imp.new_module does not function correctly if the module
	is returned from a function and used directly
In-Reply-To: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>
Message-ID: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>


New submission from Jamie Kirkpatrick <jkp at kirkconsulting.co.uk>:

See the testcase included.  If you instead assign the result of the 
get_module() call to a variable and then make the call to the function 
defined in that module it works as expected.

----------
components: Library (Lib)
files: testcase.py
messages: 94082
nosy: jkp
severity: normal
status: open
title: imp.new_module does not function correctly if the module is returned from a function and used directly
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15133/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:28:18 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Oct 2009 11:28:18 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255606098.45.0.083131160586.issue6973@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:34:08 2009
From: report at bugs.python.org (Jamie Kirkpatrick)
Date: Thu, 15 Oct 2009 11:34:08 +0000
Subject: [issue7140] imp.new_module does not function correctly if the module
	is returned from a function and used directly
In-Reply-To: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>
Message-ID: <1255606448.72.0.583941258539.issue7140@psf.upfronthosting.co.za>


Jamie Kirkpatrick <jkp at kirkconsulting.co.uk> added the comment:

Updated the testcase to show that the __dict__ for the module is incorrect 
unless the module is assigned to a temp variable.

----------
Added file: http://bugs.python.org/file15134/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:46:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Oct 2009 11:46:25 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255607185.38.0.792956239184.issue7138@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This has already been fixed with r74429, but no issue was filed at the time.

It should be backported to 2.6 and 3.1 at least.
And probably to 2.5 as well, because a crash on XML input can be
considered as a security issue.

Raising to "deferred blocker" so that it does not block 2.6.4.

----------
nosy: +amaury.forgeotdarc, barry
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:51:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 11:51:55 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255607515.94.0.863415324252.issue7080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice catch. I wonder why not all of our modules are PY_SSIZE_T_CLEAN in
py3k.
This function is not actually tested, could you add a test to the
regression suite?

----------
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Thu Oct 15 14:04:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 12:04:23 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255608263.45.0.913688206443.issue7138@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is our copy of expat in sync with upstream? How does maintenance happen?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 14:11:57 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 15 Oct 2009 12:11:57 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255608717.5.0.25552071764.issue7138@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 14:15:34 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Oct 2009 12:15:34 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255608934.03.0.104887504038.issue7138@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The same thing had been discovered in expat 12 months before:
http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmltok_impl.c?r1=1.13&r2=1.15
But expat hasn't made any release since 2.0.1, in June 2007...

Are you suggesting to update our copy of expat with its latest cvs revision?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 14:17:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 12:17:37 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255609057.37.0.847770435528.issue7138@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know really. I wonder how Linux distributions handle maintenance
of that library.
Perhaps Fred Drake can help us?

----------
assignee: effbot -> 
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 14:41:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Oct 2009 12:41:06 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255610466.92.0.744533041852.issue7138@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

FWIW, the latest Debian package: http://packages.debian.org/sid/libexpat1
is also vulnerable (I checked in the sources expat_2.0.1.orig.tar.gz,
and it's not corrected in expat_2.0.1-4.diff.tgz)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Thu Oct 15 16:13:37 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 15 Oct 2009 14:13:37 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255616017.58.0.576279665724.issue7120@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Please apply this for 2.6.4rc2

----------
priority:  -> release blocker
resolution: fixed -> accepted
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:04:36 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 15:04:36 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255619076.52.0.644761242296.issue6973@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

I agree with Milko. 

However, I think Popen.send_signal should poll() before sending any
signals, without resetting any variables to zero (or None).
In this way, if you poll() before sending a signal, if the return code
is None, the child is still running. If the poll return code is
different than None, the child has been terminated, so you must not send
anything to the child process.

In this way, instead of polling before sending signals to check if the
child has been terminated, we can make Python do the work for us.

I've provided a patch. All the tests pass.
A new test has been added: test_terminate_already_terminated_child.
This method asserts `terminate()` (through `send_signal`) raises an
OSError exception. 

However, even though you try the old version of subprocess.py all the
tests pass. This happens because the method `send_signal` calls
os.kill() (or Terminate for Windows systems) that can raise an OSError
exception if the process to which it send the signal does not exist. 
`send_signal` has been fixed to be a safer method, so that it raises an
OSError exception if the child has been terminated.

----------
keywords: +patch
nosy: +markon
Added file: http://bugs.python.org/file15135/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:05:16 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 15:05:16 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255619116.38.0.823867222441.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Added file: http://bugs.python.org/file15136/test_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:07:29 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 15:07:29 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255619249.56.0.329836537857.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file15136/test_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:08:13 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 15:08:13 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255619293.58.0.544338026715.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Added file: http://bugs.python.org/file15137/test_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:13:38 2009
From: report at bugs.python.org (egreen)
Date: Thu, 15 Oct 2009 15:13:38 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255619618.41.0.596825364715.issue7080@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

All right.

The function strcoll also isn't tested (except for issue #3303).  I'll
look into that one, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:28:34 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 15 Oct 2009 15:28:34 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

I'm in the process of converting several Python scripts so that they
work under both Python 2.6 and 3.1.  For the most part, 2to3 does an
amazing job.  Great tool.

One little feature request: could we make it add "from __future__ import
print_statement" to the top of files?

That one change is enough to make >95% of my converted scripts work fine
under 2.6 and 3.1 instead of just 3.1.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94093
nosy: stutzbach
severity: normal
status: open
title: 2to3 should add from __future__ import print_statement
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7141>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:39:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 15 Oct 2009 15:39:13 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1255621153.93.0.366136313952.issue7141@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7141>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:44:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Oct 2009 15:44:00 +0000
Subject: [issue7142] __repr__ of memoryview object has type unicode;
	should be str.
In-Reply-To: <1255621440.88.0.911779957841.issue7142@psf.upfronthosting.co.za>
Message-ID: <1255621440.88.0.911779957841.issue7142@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Objects/memoryobject.c makes calls to PyUnicode_FromString and 
PyUnicode_FromFormat.  This prevents building of Python with the --
disable-unicode option.

Here's a patch.

----------
assignee: pitrou
components: Interpreter Core
files: memoryview.patch
keywords: patch
messages: 94094
nosy: mark.dickinson, pitrou
severity: normal
stage: patch review
status: open
title: __repr__ of memoryview object has type unicode; should be str.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15138/memoryview.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7142>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:45:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Oct 2009 15:45:27 +0000
Subject: [issue7140] imp.new_module does not function correctly if the module
	is returned from a function and used directly
In-Reply-To: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>
Message-ID: <1255621527.59.0.0286501981239.issue7140@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r75437.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:51:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 15:51:20 +0000
Subject: [issue7142] __repr__ of memoryview object has type unicode;
	should be str.
In-Reply-To: <1255621440.88.0.911779957841.issue7142@psf.upfronthosting.co.za>
Message-ID: <1255621880.35.0.707944627892.issue7142@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good, obviously.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7142>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:55:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Oct 2009 15:55:36 +0000
Subject: [issue7142] __repr__ of memoryview object has type unicode;
	should be str.
In-Reply-To: <1255621440.88.0.911779957841.issue7142@psf.upfronthosting.co.za>
Message-ID: <1255622136.97.0.861811950524.issue7142@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Antoine.  Fixed in r75438.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7142>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:06:28 2009
From: report at bugs.python.org (Lance Edgar)
Date: Thu, 15 Oct 2009 17:06:28 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255626388.02.0.883565339586.issue2054@psf.upfronthosting.co.za>


Changes by Lance Edgar <lance at edbob.org>:


----------
nosy: +lgedgar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:26:34 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Oct 2009 17:26:34 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255627594.14.0.491357170182.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Are there chances to see this reviewed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:00 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629180.17.0.470044855341.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9775/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:03 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629183.73.0.318591107291.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9782/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:06 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629186.87.0.888574777897.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9783/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:10 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629190.02.0.766654863776.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9807/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:13 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629193.24.0.786542083752.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10784/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:16 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629196.35.0.439601734029.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file13161/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:53:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:53:19 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629199.94.0.852066687044.issue2054@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file13171/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:56:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 17:56:37 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255629397.86.0.604915699447.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, first some tests should be added.
As for reviewing, it needs to be done by someone competent with FTP and
SSL/TLS. If no such person is available and you are confident that the
patch is ok (and ready to do necessary maintenance), then perhaps you
can commit it. But please add tests first. It is really too easy to
accidentally break a functionality which is not exercised by the test suite.

Oh, and you need to update the documentation too :)

----------
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:06:49 2009
From: report at bugs.python.org (Andreas Thomas)
Date: Thu, 15 Oct 2009 18:06:49 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>


New submission from Andreas Thomas <raednas at gmail.com>:

The attachment of my sample email contains '123\n', but get_payload
(decode=True) returns '123'.
The source of this error is the function _bdecode from the email.utils 
module, which gets called for decoding base64 encoded payloads. Here 
the last \n gets stripped away, because (comment in the function):

# We can't quite use base64.encodestring() since it tacks on a "courtesy
# newline".  Blech!

I don't think that's true. At least not for Python 2.5.4 and upwards. 
Also note the "encodestring" instead of "decodestring".
In fact calling

base64.decodestring(part.get_payload())

returns the correct value, so I propose to remove this function 
completely and just use the standard decoding method.
Please note that base64.encodestring really tacks on a \n.

----------
components: Library (Lib)
files: test.eml
messages: 94100
nosy: athomas
severity: normal
status: open
title: get_payload(decode=True) eats last newline
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15139/test.eml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:08:52 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Oct 2009 18:08:52 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255630132.69.0.688197772058.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I can surely write tests altough I think that issue 3890 might cause 
some problems since the test server I included some months ago is 
asyncore-based and hence asynchronous.

I have a good knowledge of the FTP protocol but someone with a good 
knowledge of SSL willing to review the patch would surely be useful.


In particular I would ask Bill an update about this comment:

> Probably what I should do is fix httplib, that would  provide an 
> example we could extend to the rest of the modules.
> Bill

I don't follow the development of other stdlib modules that use ssl so 
I'm not sure how to proceed to conform with them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:15:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 18:15:52 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1255630552.33.0.974698283953.issue6721@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Rather than having a kind of global module registry, locks could keep
track of what was the last PID, and reinitialize themselves if it changed.
This is assuming getpid() is fast :-)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:27:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 18:27:38 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255631258.19.0.73560968745.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>From a quick look at the patch, if you call login() twice, the socket
will be wrapped twice as well? Perhaps auth_tls() should have a
protection against this.

In prot_p() and prot_c(), it seems that self._prot_p is updated
unconditionally, regardless of the FTP response.

In retrbinary(), retrlines(), storbinary() and storlines(), you
certainly want some try/finally blocks so that the data connection
always gets closed at the end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:34:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2009 18:34:31 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255631671.69.0.635501424626.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One more question, why is "ssl_version=ssl.PROTOCOL_TLSv1" hardwired?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:49:25 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Oct 2009 18:49:25 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1255632565.31.0.660937057079.issue3890@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Antoine asked me to give my opinion on the non-blocking SSL API.  I can
say that the current behavior of SSLSocket.recv is certainly not very
good and probably makes SSLSocket useless for any non-blocking
application.  Letting the underlying want-read/want-write error bubble
up to the caller definitely makes more sense than blocking.

I haven't had a chance to look into the new SSL code in depth, so don't
construe this as a thorough review of the change, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Thu Oct 15 21:35:21 2009
From: report at bugs.python.org (Pete Hunt)
Date: Thu, 15 Oct 2009 19:35:21 +0000
Subject: [issue7144] imp.load_module in thread causes core dump on OSX 10.6
In-Reply-To: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
Message-ID: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>


New submission from Pete Hunt <floydophone at gmail.com>:

Apologies if I mess up the formatting - my first bug report submitted.

Steps to reproduce (OSX Snow Leopard, 2.6.3)

>>> import threading, imp
>>> def doit():
...     print imp.load_module("cherrypy", None, 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-
packages/CherryPy-3.1.2-py2.6.egg/cherrypy", ('', '', 5))
... 
>>> threading.Thread(target=doit).start()
>>> Trace/BPT trap

----------
assignee: ronaldoussoren
components: Extension Modules, Interpreter Core, Macintosh
messages: 94106
nosy: peterhunt, ronaldoussoren
severity: normal
status: open
title: imp.load_module in thread causes core dump on OSX 10.6
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7144>
_______________________________________

From report at bugs.python.org  Thu Oct 15 21:41:03 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 15 Oct 2009 19:41:03 +0000
Subject: [issue7144] imp.load_module in thread causes core dump on OSX 10.6
In-Reply-To: <1255635321.71.0.461133930779.issue7144@psf.upfronthosting.co.za>
Message-ID: <1255635663.39.0.0691866947784.issue7144@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This seems to be a known issue: importing extensions in a thread fails on 
OSX 10.6 (with a hard crash of the interpreter). The crash in inside the 
initialisation function for an Apple framework. 

I haven't been able to determine if the problem is in Python or OSX, 
although it likely is a problem in the OS and is definitely a regression 
in OSX (it works on 10.5 but crashes on 10.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7144>
_______________________________________

From report at bugs.python.org  Thu Oct 15 22:55:42 2009
From: report at bugs.python.org (Yang Zhang)
Date: Thu, 15 Oct 2009 20:55:42 +0000
Subject: [issue7145] UTF-16 BOM is not written by socket.makefile (but is
	expected by read)
In-Reply-To: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>
Message-ID: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>


New submission from Yang Zhang <yaaang at gmail.com>:

When I call s.makefile('r',encoding='utf-16').read(), this expects a BOM, 
but s.makefile('w',encoding='utf-16').write('hello') doesn't produce it. 
This is asymmetric.

BTW is there a way to prevent the reading file from expecting a BOM?

----------
components: Library (Lib)
messages: 94108
nosy: yang
severity: normal
status: open
title: UTF-16 BOM is not written by socket.makefile (but is expected by read)
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________

From report at bugs.python.org  Thu Oct 15 22:58:41 2009
From: report at bugs.python.org (Yang Zhang)
Date: Thu, 15 Oct 2009 20:58:41 +0000
Subject: [issue7145] UTF-16 BOM is not written by socket.makefile (but is
	expected by read)
In-Reply-To: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>
Message-ID: <1255640321.54.0.146924375698.issue7145@psf.upfronthosting.co.za>


Yang Zhang <yaaang at gmail.com> added the comment:

To answer my own question: specify UTF-16BE or UTF-16LE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________

From report at bugs.python.org  Thu Oct 15 23:29:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Oct 2009 21:29:50 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1255642190.5.0.830910659695.issue7128@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a test+patch.
This does not apply to py3k: restricted mode does not exist there.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file15140/cpickle_restricted.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Thu Oct 15 23:31:19 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 21:31:19 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255642279.0.0.886035342767.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file15135/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Thu Oct 15 23:31:40 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 21:31:40 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255642300.74.0.0328830127855.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Added file: http://bugs.python.org/file15141/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Fri Oct 16 00:09:21 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 22:09:21 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255644561.41.0.997098556002.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file15141/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Fri Oct 16 00:09:24 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 22:09:24 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255644564.58.0.758910839391.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Removed file: http://bugs.python.org/file15137/test_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Fri Oct 16 00:09:58 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 22:09:58 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255644598.48.0.122285327841.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Added file: http://bugs.python.org/file15142/test_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Fri Oct 16 00:10:20 2009
From: report at bugs.python.org (Marco Buccini)
Date: Thu, 15 Oct 2009 22:10:20 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1255644620.8.0.361107907969.issue6973@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


Added file: http://bugs.python.org/file15143/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Fri Oct 16 01:40:49 2009
From: report at bugs.python.org (Ryan Williams)
Date: Thu, 15 Oct 2009 23:40:49 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1255650049.79.0.546488799224.issue7138@psf.upfronthosting.co.za>


Ryan Williams <rdw at lindenlab.com> added the comment:

Adding 2.5 back, looks like it was removed accidentally.

Also, here's a list of strings for testing purposes: 

['<?xml \xee\xae\x94 ?>', '<?xml \xc4\x9d ?>', '<?xml \xc8\x84 ?>',
'<?xml \xd9\xb5 ?>', '<?xml \xd9\xaa ?>', '<?xml \xc9\x88 ?>', '<?xml
\xcb\x8c ?>']

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Fri Oct 16 01:40:52 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 15 Oct 2009 23:40:52 +0000
Subject: [issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows
	and 'x86-64' on Linux
In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
Message-ID: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

Looking at http://bugs.python.org/setuptools/issue1 and reading the
source of Lib/platform.py, it appears to me that uname() returns
different strings identifying the amd64 architecture depending on what
operating system is running.  It would seem to me that it would be
better to report the same arch with the same string on all platforms.

Could someone with win64 report the output of:

python -c 'import platform;print platform.uname()[4]'

Here is a patch against trunk that just replaces any 'x86_64' with 'amd64':

HACK yukyuk:~/playground/python/trunk$ svn diff
Index: Lib/platform.py
===================================================================
--- Lib/platform.py     (revision 75443)
+++ Lib/platform.py     (working copy)
@@ -1225,6 +1225,9 @@
         system = 'Windows'
         release = 'Vista'

+    #  normalize 'amd64' arch
+    if machine == 'x86_64':
+        machine = 'amd64'
     _uname_cache = system,node,release,version,machine,processor
     return _uname_cache

----------
components: Library (Lib)
messages: 94112
nosy: zooko
severity: normal
status: open
title: [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7146>
_______________________________________

From report at bugs.python.org  Fri Oct 16 01:45:04 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Oct 2009 23:45:04 +0000
Subject: [issue7147] Remove WITHOUT_COMPLEX from 3.x trunk
In-Reply-To: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>
Message-ID: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I raised the topic of the use of WITHOUT_COMPLEX in python-dev.  Here's
a patch to remove it from the 3.x trunk.

----------
components: Interpreter Core
files: nocomplex.diff
keywords: easy, needs review, patch, patch
messages: 94113
nosy: skip.montanaro
priority: normal
severity: normal
stage: patch review
status: open
title: Remove WITHOUT_COMPLEX from 3.x trunk
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15144/nocomplex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7147>
_______________________________________

From report at bugs.python.org  Fri Oct 16 01:56:58 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 15 Oct 2009 23:56:58 +0000
Subject: [issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows
	and 'x86-64' on Linux
In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
Message-ID: <1255651018.85.0.736478288868.issue7146@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7146>
_______________________________________

From report at bugs.python.org  Fri Oct 16 02:03:47 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 16 Oct 2009 00:03:47 +0000
Subject: [issue3079] sys.exit() called from optparse - bad, bad, bad
In-Reply-To: <1213205007.57.0.132667292732.issue3079@psf.upfronthosting.co.za>
Message-ID: <1255651427.38.0.0608580673501.issue3079@psf.upfronthosting.co.za>


Phillip M. Feldman <pfeldman at verizon.net> added the comment:

The current behavior of optparse is contrary to how most of Python
works. optparse should throw a named exception that can be trapped and
identified by the calling program.  Doing a SystemExit is unacceptable.
 I can't believe that this is such a hard thing to fix.

----------
nosy: +pfeldman at verizon.net

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3079>
_______________________________________

From report at bugs.python.org  Fri Oct 16 02:24:09 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 16 Oct 2009 00:24:09 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1255630552.33.0.974698283953.issue6721@psf.upfronthosting.co.za>
Message-ID: <52dc1c820910151723h7c77ee3ctb1d99302766dce4f@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Rather than having a kind of global module registry, locks could keep
> track of what was the last PID, and reinitialize themselves if it changed.
> This is assuming getpid() is fast :-)

Locks can't blindly release themselves because they find themselves
running in another process.

If anything if a lock is held and finds itself running in a new
process any attempt to use the lock should raise an exception so that
the bug is noticed.

I'm not sure a PID check is good enough.  old linux using linuxthreads
had a different pid for every thread, current linux with NPTL is more
like other oses with the same pid for all threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Oct 16 02:36:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Oct 2009 00:36:51 +0000
Subject: [issue3079] sys.exit() called from optparse - bad, bad, bad
In-Reply-To: <1213205007.57.0.132667292732.issue3079@psf.upfronthosting.co.za>
Message-ID: <1255653411.35.0.885397210024.issue3079@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There was recently a long discussion of this on python-dev (in the
context of a proposal to add argparse to the stdlib; argparse does the
same thing).  The conclusion was that the current behavior is the most
useful behavior, and that if you don't want to exit you can either
subclass or catch SystemExit.

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3079>
_______________________________________

From report at bugs.python.org  Fri Oct 16 02:39:05 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 16 Oct 2009 00:39:05 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1255653545.53.0.0557605978167.issue1759169@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

I just tried to port a library of mine -- zfec -- to Nexenta (the Ubuntu
variant built on top of OpenSolaris).  I hit this bug because the
Nexenta folks don't use all the patches that are applied to Python by
the Solaris folks.  My port of my library is blocked until the Nexenta
folks apply this patch to their package of Python:

https://bugs.launchpad.net/python/+bug/452667 # can't compile Python
modules that use C99

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Fri Oct 16 03:24:22 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 16 Oct 2009 01:24:22 +0000
Subject: [issue7148] socket.py: r75412 broke build
In-Reply-To: <1255656261.81.0.427894588269.issue7148@psf.upfronthosting.co.za>
Message-ID: <1255656261.81.0.427894588269.issue7148@psf.upfronthosting.co.za>


New submission from Kurt B. Kaiser <kbk at shore.net>:

buildbots failing since r75412:

testSocketServer (test.test_ssl.ThreadedTests) ... Traceback (most 
recent call last):
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 282, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 308, in process_request
    self.finish_request(request, client_address)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 321, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 639, in __init__
    self.finish()
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
SocketServer.py", line 692, in finish
    self.wfile.flush()
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
socket.py", line 300, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
ssl.py", line 203, in sendall
    v = self.send(data[count:])
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
ssl.py", line 94, in <lambda>
    self.send = lambda data, flags=0: SSLSocket.send(self, data, flags)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/
ssl.py", line 174, in send
    v = self._sslobj.write(data)
TypeError: must be string or read-only buffer, not memoryview

----------
assignee: pitrou
components: Library (Lib)
messages: 94118
nosy: kbk, pitrou
priority: high
severity: normal
status: open
title: socket.py: r75412 broke build
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7148>
_______________________________________

From report at bugs.python.org  Fri Oct 16 03:33:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Oct 2009 01:33:46 +0000
Subject: [issue7148] socket.py: r75412 broke build
In-Reply-To: <1255656261.81.0.427894588269.issue7148@psf.upfronthosting.co.za>
Message-ID: <1255656826.39.0.747807778335.issue7148@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 7133, where Antoine has already proposed a
patch.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_ssl failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7148>
_______________________________________

From report at bugs.python.org  Fri Oct 16 03:47:56 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 16 Oct 2009 01:47:56 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255657676.35.0.767683235115.issue6941@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

08jpurcell  unresponsive, ignoring for now (but see suggestions below)

bdouglasoz: had a firewall blocking the subprocess, apparently works 
for her now.  I'd point out that Notepad is just an editor, IDLE gives 
you much more.  Linux is great, but IDLE works fine with Windows XP and 
since most people use Windows, we have to be sure that it does!

adgprogramming: first, bring up your task manager and make sure there 
are no python processes running.  2.6.x subprocesses can get stuck.  
Then make sure that your firewall isn't blocking socket access to 
localhost.  Then restart IDLE.  IDLE 3.1.1 may work for you since it 
has the recent enhancement that allows multiple copies of IDLE to run 
simultaneously, but it still needs interprocess access via sockets.

----------
nosy: +kbk
priority:  -> normal
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Fri Oct 16 04:21:04 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 16 Oct 2009 02:21:04 +0000
Subject: [issue7148] socket.py: r75412 broke build
In-Reply-To: <1255656261.81.0.427894588269.issue7148@psf.upfronthosting.co.za>
Message-ID: <1255659664.76.0.446948261405.issue7148@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

bah.  I looked twice for a prior bug and missed it!  Sorry....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7148>
_______________________________________

From report at bugs.python.org  Fri Oct 16 05:33:14 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 16 Oct 2009 03:33:14 +0000
Subject: [issue3079] sys.exit() called from optparse - bad, bad, bad
In-Reply-To: <1255653411.35.0.885397210024.issue3079@psf.upfronthosting.co.za>
Message-ID: <4AD7E973.4040504@verizon.net>


Phillip M. Feldman <pfeldman at verizon.net> added the comment:

Thanks for the response!

I can indeed catch SystemExit, but I would like to be able to take one 
action (terminate the program) if the user supplied an unknown option, 
and another action (prompt for a new value) if the user supplied a bad 
value for an option.  I suspect that I can achieve this by subclassing, 
but I'm not yet at that level of Python sophistication.

Yours,

Phillip

R. David Murray wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> There was recently a long discussion of this on python-dev (in the
> context of a proposal to add argparse to the stdlib; argparse does the
> same thing).  The conclusion was that the current behavior is the most
> useful behavior, and that if you don't want to exit you can either
> subclass or catch SystemExit.
>
> ----------
> nosy: +r.david.murray
> resolution:  -> wont fix
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3079>
> _______________________________________
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3079>
_______________________________________

From report at bugs.python.org  Fri Oct 16 05:53:55 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 16 Oct 2009 03:53:55 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255665235.35.0.65341038727.issue7133@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Reviewed, built, tests ok.

Linux trader 2.6.18-ARCH #1 SMP PREEMPT Sun Nov 19 09:14:35 CET 2006 
i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux

vote +1  weight +0.1 :-)

----------
nosy: +kbk
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________

From report at bugs.python.org  Fri Oct 16 06:49:58 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 04:49:58 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Possible Release Blocker

A number of proxy test cases in test_urllib2 are now failing with:

ERROR: test_proxy (test.test_urllib2.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/test/te
st_urllib2.py", line 940, in test_proxy
    r = o.open(req)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 389, in open
    response = self._open(req, data)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 407, in _open
    '_open', req)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 367, in _call_chain
    result = func(*args)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 696, in <lambda>
    meth(r, proxy, type))
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2
.py", line 705, in proxy_open
    if req.host and proxy_bypass(req.host):
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1398, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File 
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.
py", line 1367, in proxy_bypass_macosx_sysconf
    if hostIP is None:
UnboundLocalError: local variable 'hostIP' referenced before assignment

The root cause is the problem identified in Issue7044.  This is now 
showing up in test_urllib2 because of the changes in urllib2 introduced 
by Issue6894 which was checked into the release-26maint branch during 
the window between the release of 2.6.3 and the freezing for 2.6.4.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 94124
nosy: barry, ned.deily, orsenthil, ronaldoussoren
severity: normal
status: open
title: 2.6.4rc1 regression: test_urllib2 fails on OS X with UnboundLocalError
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 06:51:01 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 04:51:01 +0000
Subject: [issue7044] urllib.urlopen crashes when used on Mac OS 10.6.1 through
	a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1255668661.46.0.520163756621.issue7044@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See also Issue7149.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7044>
_______________________________________

From report at bugs.python.org  Fri Oct 16 06:53:19 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Oct 2009 04:53:19 +0000
Subject: [issue7044] urllib.urlopen crashes when used on Mac OS 10.6.1 through
	a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1255668799.35.0.0586653440178.issue7044@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7044>
_______________________________________

From report at bugs.python.org  Fri Oct 16 07:08:53 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 16 Oct 2009 05:08:53 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255669733.05.0.924212302875.issue7149@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Barry: this should be a release blocker, I introduced the problem around 
or after 2.6.3 :-(

When do you cut rc2? I probably won't be able to provide a patch myself 
until Saturday afternoon (CEST).

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 07:49:36 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Oct 2009 05:49:36 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255672176.08.0.196263318744.issue7149@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

In the Issue7044, the reporter has identified the root cause and
possible fix too.
"
In Python 2.6.3 on Mac OS 10.6.1, there is a bug in 
lib/python2.6/urllib.py, line 1367. The variable hostIP is used before 
it's defined. You can fix it by adding "hostIP = None" at around line 
1355.
"

That change might fix both the issues. 

I don't have a OS X to verify the fix tough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 08:47:02 2009
From: report at bugs.python.org (Ehsan Amiri)
Date: Fri, 16 Oct 2009 06:47:02 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1255675622.45.0.342150480661.issue7143@psf.upfronthosting.co.za>


Changes by Ehsan Amiri <ehsanamiri at gmail.com>:


----------
nosy: +esam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Fri Oct 16 09:22:06 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 16 Oct 2009 07:22:06 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255677726.58.0.975157568997.issue7149@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a patch for the trunk that fixes the issue and passes 
test_urllib.py on the trunk.

What I haven't done yet is write some unittests that actually test 
different proxy configurations, that would require changing the 
SystemConfigation proxy settings (that is, the settings you set using 
the Network panel in "System Preferences"). 

Doing that is non-trivial, especially because running the tests should 
affect the rest of the system. It should be possible though to 
temporarily change the settings for the currently running process.

----------
Added file: http://bugs.python.org/file15145/urllib-hostIP-error.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 09:22:53 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 16 Oct 2009 07:22:53 +0000
Subject: [issue7044] urllib.urlopen crashes when used on Mac OS 10.6.1 through
	a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1255677773.9.0.870540872099.issue7044@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've posted a patch for this in Issue7149.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7044>
_______________________________________

From report at bugs.python.org  Fri Oct 16 09:56:16 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 07:56:16 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255679776.16.0.236827297133.issue7149@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I'll test it on 2.6 later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 10:50:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Oct 2009 08:50:26 +0000
Subject: [issue7147] Remove WITHOUT_COMPLEX from 3.x trunk
In-Reply-To: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>
Message-ID: <1255683026.56.0.545074734506.issue7147@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this patch should be applied, on the basis that:

 - the WITHOUT_COMPLEX macro doesn't appear to be documented, or
   linked to any existing configure option

 - there aren't enough developer and/or buildbot cycles to
   keep obscure options like this well tested and maintained

 - building py3k with -DWITHOUT_COMPLEX currently fails anyway

 - the complex type is (slightly) more tightly integrated in
   py3k than in trunk, thanks to PEP 3141:  (-1)**0.5 produces
   a complex result in py3k; in trunk it gives ValueError.

Any objections to getting rid of WITHOUT_COMPLEX?

The patch itself looks fine to me.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7147>
_______________________________________

From report at bugs.python.org  Fri Oct 16 11:45:30 2009
From: report at bugs.python.org (mark.leander)
Date: Fri, 16 Oct 2009 09:45:30 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>


New submission from mark.leander <mark.leander at oikku.net>:

The datetime module documentation would imply that operations that cause
dates to fall outside the MINYEAR--MAXYEAR range should raise
OverflowError. The interpreter session below shows that this is not
always the case, and that such operations may cause bogus and
inconsistent results.

Python 2.6.3 (r263rc1:75186, Oct  2 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t0=datetime.datetime(1,1,1)
>>> d1, d2, d3 = map(datetime.timedelta, range(1,4))
# The following is expected and accoring to the docs:
>>> t0-d1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range

# The following is completely bogus:
>>> t0-d2
datetime.datetime(1, 0, 255, 0, 0)

# The two following behaving differently may be very confusing,
# the second one is correct
>>> t0-d2+d3
datetime.datetime(1, 8, 15, 0, 0)
>>> t0+d3-d2
datetime.datetime(1, 1, 2, 0, 0)
>>>

----------
components: Library (Lib)
messages: 94132
nosy: mark.leander
severity: normal
status: open
title: datetime operations spanning MINYEAR give bad results
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Fri Oct 16 12:23:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Oct 2009 10:23:12 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1255688592.25.0.784748345616.issue6721@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I was suggesting "reinitialize", rather than "release". That is, create
a new lock (mutex, semaphore, etc.) and let the old one die (or occupy
some tiny bit of memory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Oct 16 12:23:26 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 16 Oct 2009 10:23:26 +0000
Subject: [issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows
	and 'x86-64' on Linux
In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
Message-ID: <1255688606.95.0.843063737534.issue7146@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Zooko O'Whielacronx wrote:
> > 
> > Looking at http://bugs.python.org/setuptools/issue1 and reading the
> > source of Lib/platform.py, it appears to me that uname() returns
> > different strings identifying the amd64 architecture depending on what
> > operating system is running.  It would seem to me that it would be
> > better to report the same arch with the same string on all platforms.
platform.py generally follows (or tries to follow) the standards
for naming things on each platform. It does not try to streamline
naming standards across various OSes and platforms.

For 64-bit x86 compatible platforms, the names "x86_64", "amd64"
and "x64" are in common use.

Since the proposal relates to setuptools, I'd suggest to
do any such streamlining there, if needed and found necessary.

For matching a binary to a system configuration you only to need
to make sure that the name used for that particular system is
the same.

Since os.uname() does not exist on Windows, platform.uname()
can be used for this purpose.

What we could do is add a new API that returns canonical names
for the various platforms. That function could then return
"amd64" for AMD 64-bit architecture compatible processors.

I'm also thinking about adding a function to do platform
matching to platform.py: the function would take two
uname() results (or part thereof) and return True/False
depending on whether the platforms are binary compatible
or not.

Some background on the used 64-bit platform names:

MS started out with calling the 64-bit x86 compatible processors
"AMD64" and used "IA64" for the Itanium processor family. More
recently they switched to calling 64-bit versions "x64" and since
support for the Itanium processor family is being phased out this
will soon become the only name used for the 64-bit version of
Windows.

Cygwin on Windows uses "x86_64", FreeBSD uses "amd64", Linux
uses "x86_64". Mac OS X uses "x86_64" for Intels (and "ppc64"
for PowerPCs).

Resources:
http://www.stata.com/support/faqs/win/64bit.html
http://www.microsoft.com/servers/64bit/overview.mspx
http://www.cygwin.com/ml/cygwin/2005-10/msg00688.html
http://en.wikipedia.org/wiki/X86-64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7146>
_______________________________________

From report at bugs.python.org  Fri Oct 16 12:28:43 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 16 Oct 2009 10:28:43 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1255688923.74.0.0855643142774.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

no need for that.  the problem is that they're held by a thread that
does not exist in the newly forked child process so they will never be
released in the new process.

example: if you fork while another thread is in the middle of logging
something and then try to log something yourself in the child, your
child process will deadlock on the logging module's lock.

locks are not shared between processes so reinitializing them with a new
object wouldn't do anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Oct 16 12:40:17 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Oct 2009 10:40:17 +0000
Subject: [issue1285440] Digest Authentication not working in all cases
Message-ID: <1255689617.52.0.79646504023.issue1285440@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I am inclined to reject this issue and close it as:
1) Digest Authentication does with urllib2
2) This is specific with some domain, which does not give enough details
to reproduce it.
3) The report is way old (2005).
If there are any new issues with Digest Authentication, lets handle it
in  a new issue with more details.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285440>
_______________________________________

From report at bugs.python.org  Fri Oct 16 14:36:29 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 16 Oct 2009 12:36:29 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255696589.1.0.168835223379.issue7149@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Agreed this is a release blocker for 2.6.4rc2.

I plan on tagging the release some time Saturday, probably around 1600
UTC.  Do you think you can add a test and apply the patch by then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 14:37:07 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 16 Oct 2009 12:37:07 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255696627.31.0.293474094423.issue7092@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Making this a deferred blocker so as not to clutter 2.6.4 release.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Oct 16 16:09:01 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 16 Oct 2009 14:09:01 +0000
Subject: [issue7120] logging depends on multiprocessing
In-Reply-To: <1255482246.24.0.333134064437.issue7120@psf.upfronthosting.co.za>
Message-ID: <1255702141.05.0.00133348384965.issue7120@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and py3k (r75445).

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7120>
_______________________________________

From report at bugs.python.org  Fri Oct 16 16:58:52 2009
From: report at bugs.python.org (jweber)
Date: Fri, 16 Oct 2009 14:58:52 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255705132.72.0.551819439126.issue7149@psf.upfronthosting.co.za>


Changes by jweber <jacob at jacobweber.com>:


----------
nosy: +jweber

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Fri Oct 16 18:26:11 2009
From: report at bugs.python.org (Nick Touran)
Date: Fri, 16 Oct 2009 16:26:11 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1255710371.71.0.264062735901.issue4120@psf.upfronthosting.co.za>


Nick Touran <nick at partofthething.com> added the comment:

Just to share my recent experience with this issue: I was attempting to
get Python 2.6 working with py4mpi, matplotlib, and pymssql on a 64-bit
Windows Vista based HPC cluster via x-copy deployment without the charm
of administrative privileges on the server and on my workstation (which
is XP). It wasn't easy, but I got it working. 

I attempted to apply the patch listed here and recompile the packages
that complained about Side-by-side configurations, but got in too deep
while compiling matplotlib on windows (recall I don't have admin
privileges and can't install the prereqs) so I dug deeper.

I found this: http://blog.kalmbachnet.de/?postid=80 which suggests
removing the publicKeyToken attribute from the manifests to force local
DLLs. This would possibly give the same effect as not embedding the
manifests in the first place using the patch. So I went in, using
VS2008, and removed this attribute from the embedded manifests in
python26.dll, python.exe, and the manifest file in C:\python26. I also
copied msvcm90.dll, msvcp90.dll, and msvcr90.dll from the 9.0.21022.8
folder in c:\Windows\WinSxS into c:\Python26. With that, matplotlib
started working, but pymssql still did not.

I then renamed _mssql.pyd to _mssql.dll so that VS2008 could recognize
the manifest, removed the publicKeyToken attribute, and renamed it back
to _mssql.pyd, but it still complained. Finally, using depends.exe from
the internet, I noticed msvcr71.dll was required on my local machine, so
I tried copying it over to the remote machine, into the site-packages
folder. Bam. It worked. So while I don't really consider this a
solution, it definitely worked for what I needed. Any other 3rd party
modules that complain in the future in my weird xcopy-deployment will
undergo manifest-stripping via VS2008 and other dependency checking via
depends.exe. Yay.

By the way, the pymssql was compiled with VS2005, which is why it
requires msvcr71.dll. If I could rebuild it with VS2008, I imagine that
step wouldn't be necessary. While I do have VS2008 on hand, I don't have
MS SQL 2020 Super Awesome Developer Edition, or whatever 3GB package
installs the required header.

----------
nosy: +ntouran

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Fri Oct 16 18:28:49 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 16 Oct 2009 16:28:49 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1255710529.07.0.0401766975697.issue7077@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

According to information from Martin von L?wis - see

http://mail.python.org/pipermail/python-dev/2009-October/092825.html

- UTF-8 should always be used, with a BOM, when sending Unicode
(according to RFC 5424). The fix will use this approach. No encoding
parameter will be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7077>
_______________________________________

From report at bugs.python.org  Fri Oct 16 19:33:02 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Oct 2009 17:33:02 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1255714382.56.0.145149473945.issue5753@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:43:25 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Oct 2009 18:43:25 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255718605.33.0.0816164650188.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> From a quick look at the patch, if you call login() twice, the socket
> will be wrapped twice as well? Perhaps auth_tls() should have a
> protection against this.

You're right. Done.

> In prot_p() and prot_c(), it seems that self._prot_p is updated
> unconditionally, regardless of the FTP response.

Both PROT P and PROT C commands expect a 2xx response.
That's why I used voidcmd(). If a response different than 2xx is 
received voidcmd() automatically raises an error_reply exception already 
and self._prot_p doesn't get set.

> One more question, why is "ssl_version=ssl.PROTOCOL_TLSv1" hardwired?

You're right, it shouldn't be.
This is now provided as a class attribute.
The reason I used PROTOCOL_TLSv1 instead of PROTOCOL_SSLv23 (the ssl.py 
default) is because RFC-4217 recommends it.

> In retrbinary(), retrlines(), storbinary() and storlines(), you
> certainly want some try/finally blocks so that the data connection
> always gets closed at the end.

I agree, it's a good practice.
I avoided to do that because the original FTP class is coded like that.
Anyway, this is done too now.

Modified patch is in attachment.

I hope I'll be able to work on tests and documentation during this week-
end.

----------
Added file: http://bugs.python.org/file15146/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:47:47 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Oct 2009 18:47:47 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255718867.48.0.896324656581.issue2054@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


Removed file: http://bugs.python.org/file15146/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:48:02 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Oct 2009 18:48:02 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255718882.19.0.513031542823.issue2054@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


Added file: http://bugs.python.org/file15147/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:51:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Oct 2009 18:51:16 +0000
Subject: [issue7151] regrtest -j sometimes fails if output gets written to
	stderr by a test
In-Reply-To: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
Message-ID: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In certain circumstances output written to stderr during a test comes
after the json result string the -j code is expecting to see at the end
of the returned subprocess output.  This causes that regrtest worker
thread to fail.  This problem is more acute on py3k; perhaps the new io
library is more likely to delay output of stderr.

Attached is a patch that avoids the problem by capturing stderr
separately.  This means that all stderr output will be after all regular
output, which changes the output of the test suite slightly (eg: in a
debug build all the refcount messages come after the output from
test_subprocess).  This seems like a small enough issue that it isn't
worth the code complexity required to code around it, especially since
the ordering of the interleaving of the two streams isn't guaranteed
even without -j.

----------
assignee: pitrou
components: Tests
files: regrtestj3stderr.patch
keywords: patch, patch
messages: 94143
nosy: pitrou, r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: regrtest -j sometimes fails if output gets written to stderr by a test
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15148/regrtestj3stderr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7151>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:06:44 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 16 Oct 2009 19:06:44 +0000
Subject: [issue7152] urllib2.build_opener() skips ProxyHandler
In-Reply-To: <1255720004.18.0.991850721386.issue7152@psf.upfronthosting.co.za>
Message-ID: <1255720004.18.0.991850721386.issue7152@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Try this:

>>> from urllib2 import build_opener
>>> build_opener().handlers

In Python 2.4, you will see ProxyHandler as the first handler, but this
handler is missing from the list in Python 2.5, 2.6, and 2.7, despite this
text in the documentation:

    urllib2.build_opener([handler, ...])

    Return an OpenerDirector instance, which chains the handlers in the
order
    given. handlers can be either instances of BaseHandler, or subclasses of
    BaseHandler (in which case it must be possible to call the constructor
    without any parameters). Instances of the following classes will be in
    front of the handlers, unless the handlers contain them, instances
of them
    or subclasses of them: ProxyHandler, UnknownHandler, HTTPHandler,
    HTTPDefaultErrorHandler, HTTPRedirectHandler, FTPHandler, FileHandler,
    HTTPErrorProcessor.

In fact, there is no way to add a ProxyHandler at all using the public API.
This is because the following code was added to Python 2.5, purportedly as a
fix for bug 972322:

    http://bugs.python.org/issue972322

# urllib2.py:307

            if meth in ["redirect_request", "do_open", "proxy_open"]:
                # oops, coincidental match
                continue

Because of this, the following are not a workarounds:

>>> opener.add_handler(ProxyHandler)
>>> build_opener(ProxyHandler())

In fact, as near as I can tell, the only way to get a ProxyHandler in
there is
to do an end-run around .add_handler():

>>> proxy_handler = ProxyHandler()
>>> opener.handlers.insert(0, proxy_handler)
>>> proxy_handler.add_parent(opener)

I'm actually quite shocked this has never been reported before.

ISTM that the right fix is what was originally suggested in bug 972322:

    http://bugs.python.org/msg46172

"The alternative would be to rename do_open and proxy_open, and leave the
redirect_request case unchanged (see below for why)."

The intent of this patch could not have been to completely prevent
ProxyHandler from being included in the list of handlers, otherwise why keep
ProxyHandler at all?  If that was the case, then the documentation for
urllib2
is broken, and it should have described this change as occurring in Python
2.5.

----------
components: Library (Lib)
messages: 94144
nosy: barry
priority: high
severity: normal
stage: needs patch
status: open
title: urllib2.build_opener() skips ProxyHandler
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7152>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:24:03 2009
From: report at bugs.python.org (paul rubin)
Date: Fri, 16 Oct 2009 19:24:03 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>


New submission from paul rubin <phr at users.sourceforge.net>:

Lots of times I want to find the largest element of a list or sequence,
defaulting to 0 if the list or sequence is empty.  max(seq) throws an
exception if seq is empty, so I end up using reduce(max, seq, 0).  That
is a standard functional programming idiom but can be a bit confusing to
imperative-style Python programmers.  

max with multiple args is already overloaded to mean the maximum of the
args, so I think it would be a good fix to add a keyword arg to accept
an optional initial value:  max(seq, start=0).  For symmetry, min should
accept the same arg.

The alternatives to using reduce aren't so attractive.  If seq happens
to be a list, there might be a temptation to conditionalize on
len(seq)==0, but that is poor style since it will break if seq later
changes to an arbitrary sequence.  And trying to test it by calling
.next() and saving the value and/or trapping StopIteration gets awfully
messy.

----------
components: Library (Lib)
messages: 94145
nosy: phr
severity: normal
status: open
title: add "start" arg to max and min functions
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:31:42 2009
From: report at bugs.python.org (adgprogramming)
Date: Fri, 16 Oct 2009 19:31:42 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255721502.78.0.13237005224.issue6941@psf.upfronthosting.co.za>


adgprogramming <knd_adam at yahoo.com> added the comment:

Thanks so much! It works perfect!

There was a process running that had to do with pythonw.exe and 
idle.bat. My firewall also blocked access to those same programs. 
Thanks!

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:34:03 2009
From: report at bugs.python.org (paul rubin)
Date: Fri, 16 Oct 2009 19:34:03 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255721643.32.0.975223089385.issue7153@psf.upfronthosting.co.za>


Changes by paul rubin <phr at users.sourceforge.net>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:13:39 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Oct 2009 20:13:39 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255724019.94.0.238500916918.issue7153@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:53:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Oct 2009 20:53:35 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255726415.04.0.721668089146.issue7153@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In case you don't remember it, this thread from python-ideas is relevant:

http://mail.python.org/pipermail/python-ideas/2009-April/004107.html

I can't tell from rereading the thread whether the support was for the
'initial' version, or the 'default' version that was more-or-less
rejected as being too confusing.  If the support was for the initial
version then that would be support for this proposal.

----------
nosy: +r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:03:18 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Fri, 16 Oct 2009 21:03:18 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1255726998.1.0.252951021719.issue6717@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I've written and appended with this message a small script using
tkinter, that produces the same crash as described earlier with turtle.py:

tkinter_recursion_31.py

It occurs when heavily and fast dragging the red square. So the bug
doesn't depent on turtle.py

I'd like to mention again, that the corresponding script under Python26
does crash also, but with a regular Python Error-Message. It does not
kill IDLE when stated from within IDLE.

So I'd suggest to give this one a higher priority. Should be fixed with 3.2

Regards,
Gregor

----------
Added file: http://bugs.python.org/file15149/tkinter_recursionbug_31.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:05:56 2009
From: report at bugs.python.org (Marco Buccini)
Date: Fri, 16 Oct 2009 21:05:56 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1255727156.67.0.409203106916.issue6975@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

I've provided a patch.

I've also added a new test, and it passes.

----------
keywords: +patch
nosy: +markon
Added file: http://bugs.python.org/file15150/issue6975.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:06:24 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 16 Oct 2009 21:06:24 +0000
Subject: [issue7152] urllib2.build_opener() skips ProxyHandler
In-Reply-To: <1255720004.18.0.991850721386.issue7152@psf.upfronthosting.co.za>
Message-ID: <1255727184.59.0.607428302179.issue7152@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This may end up being just a documentation issue.  If the environment
has http_proxy set, you do get a ProxyHandler automatically.

>>> import os
>>> os.environ['http_proxy'] = 'localhost'
>>> from urllib2 import build_opener
>>> build_opener().handlers
[<urllib2.ProxyHandler instance at 0x7fb664ec6e18>,
<urllib2.UnknownHandler instance at 0x7fb664eca050>,
<urllib2.HTTPHandler instance at 0x7fb664eca710>,
<urllib2.HTTPDefaultErrorHandler instance at 0x7fb664ecaa70>,
<urllib2.HTTPRedirectHandler instance at 0x7fb664ecad88>,
<urllib2.FTPHandler instance at 0x7fb664ecae60>, <urllib2.FileHandler
instance at 0x7fb664ecaf38>, <urllib2.HTTPSHandler instance at
0x7fb664ece3b0>, <urllib2.HTTPErrorProcessor instance at 0x7fb664ece128>]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7152>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:11:25 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Oct 2009 21:11:25 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1255727485.59.0.736163580604.issue1068268@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:11:34 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Oct 2009 21:11:34 +0000
Subject: [issue4216] subprocess.Popen hangs at communicate() when child exits
In-Reply-To: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za>
Message-ID: <1255727494.25.0.081359274659.issue4216@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4216>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:44:12 2009
From: report at bugs.python.org (paul rubin)
Date: Fri, 16 Oct 2009 21:44:12 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255729452.8.0.637101438633.issue7153@psf.upfronthosting.co.za>


paul rubin <phr at users.sourceforge.net> added the comment:

David, I'm not on that mailing list so hadn't seen the earlier
discussion.  I sympathasize with Raymond's YAGNI argument because I'm
comfortable with reduce(max,seq,0); but then I remember there was once a
movement to remove the "reduce" function from builtins, which would have
broken that idiom.  I also understand that not everyone is comfortable
with that style.  I recently had to hand over some code to another
programmer where I had used that idiom, and in the course of adding
comments to the code in preparation for the handover, I found myself
writing quite a few words about why I'd used "reduce" that way, so I
figured that "explicit is better than implicit" suggests adding default
or initial args to the max function, just like "reduce" already has (I
figure that max on a sequence is a special case of reduce).

My proposed python implementation:

def mymax(*args, **kwargs):
  if len(args) > 1: return max(*args)
  if len(args) == 0: raise TypeError, "mymax needs at least one
positional arg"
  if 'initial' in kwargs: return reduce(max,args[0],kwargs['initial'])
  return reduce(max,args[0])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:21:21 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 22:21:21 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255731681.46.0.607167964885.issue7149@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The supplied patch looks good and applies cleanly to 2.6 as well.  I built 
and tested it with both 2.6 and trunk and the tests now all pass as 
expected.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:46:48 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 22:46:48 +0000
Subject: [issue7154] urllib.request system proxy configuration lookup broken
	for OS X in Python 3
In-Reply-To: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>
Message-ID: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

On OS X, urllib.request in Python 3 is supposed to use the operating 
system's proxy configuration by default, unless overridden by 
environment variables or by the caller providing an explicit proxy 
configuration.

In Python 2, urllib (and, indirectly, urllib2) were modified to use the 
OS X SystemConfiguration framework API instead of the obsolete classic 
MacOS Internet Configuration via the deprecated Macintosh ic library 
module, which was removed in Python 3.

However, in the transition from Python 2 urllib/urllib2 to Python 3 
urllib.request, the changes to the darwin-specific getproxies functions 
were not made.  So, at the moment, Python 3 urllib.request tries to 
import the non-existant ic module and silently fails, effectively 
ignoring the system proxy configuration.  The solution is to forward 
port the corresponding code from Python 2 urllib along with the helper 
module _scproxy.c.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 94153
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: urllib.request system proxy configuration lookup broken for OS X in Python 3
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7154>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:55:43 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 22:55:43 +0000
Subject: [issue5475] urllib2.getproxies not documented
In-Reply-To: <1236766495.94.0.773728136477.issue5475@psf.upfronthosting.co.za>
Message-ID: <1255733743.88.0.966005679813.issue5475@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

In Python 2, urllib2.getproxies is one of a number of helper functions 
imported from urllib.  It's not externally documented there, either, and 
likely not intended to be used externally.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5475>
_______________________________________

From report at bugs.python.org  Sat Oct 17 01:45:27 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Oct 2009 23:45:27 +0000
Subject: [issue7155] urllib2 and python 3 urllib do not document default use
	of system proxy configuration
In-Reply-To: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>
Message-ID: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Several issues with urllib/urllib2 documentation regarding proxy usage:

1. The Macintosh proxy description in section 21.5.1 is out-of-date:

    "In a Macintosh environment, urlopen() will retrieve
     proxy information from Internet Config."

   Suggest something like:

    "In a Mac OS X environment, urlopen() will retrieve
     proxy information from the OS X System Configuration
     framework, which can be managed with the Network system
     preference panel." 

2. In general, urllib/urllib2 on Python 2 and urllib.request on Python 3
   are supposed to default to using the OS's proxy configuration on 
   Windows and OS X if not overridden by environment variables or
   if not supplied as an argument.  This is described in python 2 docs
   section 21.5.1. urllib2 has the same default behavior since under the
   covers it uses urllib's proxy functions.  But that behavior is not
   documented in 21.6 for urllib2 in the various spots where proxy is
   mentioned.

3. Likewise, the corresponding sections of the Python 3 documentation
   for urllib.request (section 20.5) do not mention the default system
   proxy configuration behavior and should since that code was carried
   over from Python 2 (although, at the moment, the OS X code is broken
   - see Issue7154).

----------
assignee: georg.brandl
components: Documentation
messages: 94155
nosy: georg.brandl, ned.deily
severity: normal
status: open
title: urllib2 and python 3 urllib do not document default use of system proxy configuration
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7155>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:25:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Oct 2009 00:25:22 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255739122.22.0.682499483756.issue7149@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

BTW, I did test manually changing the system proxy configuration via the 
Network preference panel and verified that urllib/urllib2 used the default 
proxy settings.  I suppose it would be possible to set up some tests using 
the OS X scutil command but it would be tricky to do 100% safely, I'd 
think.  In any case, it's clear that the urllib2 tests do provide some 
test coverage in this area, witness this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:28:56 2009
From: report at bugs.python.org (Archon)
Date: Sat, 17 Oct 2009 00:28:56 +0000
Subject: [issue7156] curses can't find _curses
Message-ID: <1255739336.81.0.0557140731973.issue7156@psf.upfronthosting.co.za>


Changes by Archon <mddekock at bendbroadband.com>:


----------
components: Library (Lib)
nosy: Archon
severity: normal
status: open
title: curses can't find _curses
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7156>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:29:48 2009
From: report at bugs.python.org (Archon)
Date: Sat, 17 Oct 2009 00:29:48 +0000
Subject: [issue7156] curses can't find _curses
In-Reply-To: <1255739388.85.0.756737488331.issue7156@psf.upfronthosting.co.za>
Message-ID: <1255739388.85.0.756737488331.issue7156@psf.upfronthosting.co.za>


New submission from Archon <mddekock at bendbroadband.com>:

When I try to import curses, it returns the error:

Traceback (most recent call last):
  File "C:\Python31\Lib\curses\__init__.py", line 15, in <module>
    from _curses import *
ImportError: No module named _curses

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7156>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:40:19 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sat, 17 Oct 2009 00:40:19 +0000
Subject: [issue7157] Fix Download Current Documentation link
In-Reply-To: <1255740019.91.0.5088264353.issue7157@psf.upfronthosting.co.za>
Message-ID: <1255740019.91.0.5088264353.issue7157@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

http://docs.python.org/download.html shows this:

----

Download Python 2.6.4c1 Documentation

We don't package the documentation for development releases for
download. Downloads will be available for the final release.

----

This is not really acceptable for someone navigating through python.org
to the Documentation page. The latest 2.6 reference, tutorial, etc, are
all available, and so the archives with the latest PDF versions should
be too.

----------
assignee: georg.brandl
components: Documentation
messages: 94158
nosy: georg.brandl, ryles
severity: normal
status: open
title: Fix Download Current Documentation link
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7157>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:03:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2009 01:03:36 +0000
Subject: [issue7156] curses can't find _curses
In-Reply-To: <1255739388.85.0.756737488331.issue7156@psf.upfronthosting.co.za>
Message-ID: <1255741416.65.0.591968243304.issue7156@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried with several versions of Python and Windows and I got the same
error on all, so I think it's normal.
The documentation is not clear about that though, so it should be added
a paragraph that explain why it doesn't work and if/how it's possible to
make it work.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +ezio.melotti, georg.brandl
priority:  -> normal
type: crash -> behavior
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7156>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:07:25 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2009 01:07:25 +0000
Subject: [issue7157] Fix Download Current Documentation link
In-Reply-To: <1255740019.91.0.5088264353.issue7157@psf.upfronthosting.co.za>
Message-ID: <1255741645.36.0.109365461327.issue7157@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7157>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:09:48 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2009 01:09:48 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1255741788.62.0.627185036919.issue6975@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:10:55 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2009 01:10:55 +0000
Subject: [issue7145] UTF-16 BOM is not written by socket.makefile (but is
	expected by read)
In-Reply-To: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>
Message-ID: <1255741855.34.0.136641108424.issue7145@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:11:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2009 01:11:54 +0000
Subject: [issue7127] regrtest -j fails when tests write to stderr
In-Reply-To: <1255536423.67.0.1834189118.issue7127@psf.upfronthosting.co.za>
Message-ID: <1255741914.25.0.244336247548.issue7127@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7127>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:18:03 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 17 Oct 2009 01:18:03 +0000
Subject: [issue1378] fromfd() and dup() for _socket on WIndows
In-Reply-To: <1254677966.86.0.564825577539.issue1378@psf.upfronthosting.co.za>
Message-ID: <20091017011748.GB4048@ubuntu.ubuntu-domain>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Oct 04, 2009 at 05:39:26PM +0000, Preston Landers wrote:
> I'm curious what happened with this issue.  It says closed+accepted but
> it doesn't appear to be checked in. 

If you see the report, the last message indicates that it is checked in revision 59004.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1378>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:20:04 2009
From: report at bugs.python.org (=?utf-8?q?Patrick_N=C3=A4f?=)
Date: Sat, 17 Oct 2009 01:20:04 +0000
Subject: [issue2897] include structmember.h in Python.h
In-Reply-To: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
Message-ID: <1255742404.91.0.407809514528.issue2897@psf.upfronthosting.co.za>


Changes by Patrick N?f <herzbube at herzbube.ch>:


----------
nosy: +herzbube

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2897>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:22:16 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 17 Oct 2009 01:22:16 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1255742536.84.0.404999369676.issue1673007@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Sat Oct 17 05:24:18 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 17 Oct 2009 03:24:18 +0000
Subject: [issue7155] urllib2 and python 3 urllib do not document default use
	of system proxy configuration
In-Reply-To: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>
Message-ID: <1255749858.88.0.31155365686.issue7155@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I have attached a docs patch against the trunk.
Please provide your review comments. If its okay, I can commit it and
have the information (urllib2.rst) for the Python 3k too.

----------
assignee: georg.brandl -> orsenthil
keywords: +patch
nosy: +orsenthil
resolution:  -> accepted
Added file: http://bugs.python.org/file15151/issue7155-docspatch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7155>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:17:29 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Oct 2009 04:17:29 +0000
Subject: [issue7155] urllib2 and python 3 urllib do not document default use
	of system proxy configuration
In-Reply-To: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>
Message-ID: <1255753049.91.0.0161597454664.issue7155@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

One comment:
+   :envvar:`<protocol>_proxy`.  In a Windows environment, if no proxy
+   environment variables are set, proxy settings are obtained from the
+   registry's Internet Settings section.  In a Mac OS X  environment, 
proxy
+   information is retrieved from from the OS X System Configuration 
Framework.

The "if no proxy environment variables are set" part applies to OS X as 
well so perhaps:

  If no proxy environment variables are set, in a Windows environment 
... and in a Mac OS X environment ... .

Otherwise looks good. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7155>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:22:55 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Oct 2009 04:22:55 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1255753375.8.0.103496611277.issue5625@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

While you're poking around in urllib2, perhaps I can interest you in 
looking at these patches.

----------
nosy: +orsenthil
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:29:54 2009
From: report at bugs.python.org (Ehsan Amiri)
Date: Sat, 17 Oct 2009 04:29:54 +0000
Subject: [issue4688] GC optimization: don't track simple tuples and dicts
In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za>
Message-ID: <1255753794.21.0.128932645515.issue4688@psf.upfronthosting.co.za>


Changes by Ehsan Amiri <ehsanamiri at gmail.com>:


----------
nosy: +esam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4688>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:33:01 2009
From: report at bugs.python.org (Ehsan Amiri)
Date: Sat, 17 Oct 2009 04:33:01 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1255753981.79.0.847475530145.issue4715@psf.upfronthosting.co.za>


Changes by Ehsan Amiri <ehsanamiri at gmail.com>:


----------
nosy: +esam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:46:04 2009
From: report at bugs.python.org (Ehsan Amiri)
Date: Sat, 17 Oct 2009 04:46:04 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255754764.51.0.14171629945.issue7153@psf.upfronthosting.co.za>


Changes by Ehsan Amiri <ehsanamiri at gmail.com>:


----------
nosy: +esam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Sat Oct 17 07:01:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Oct 2009 05:01:37 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255755697.75.0.558446275854.issue7153@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, that "in case you don't remember' was directed at Raymond, not you.

Since Raymond took ownership of this issue I don't think he's dismissing
it (at least not yet :)  I think his YAGNI was for the 'default'
version, which is not what you are proposing.

Note that 'reduce' is _not_ a builtin in Python3, although it is still
available and so the idiom is not broken, just slightly wordier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Sat Oct 17 07:26:01 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Oct 2009 05:26:01 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255757161.31.0.646759678586.issue3366@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

FYI, approximately 20 of the gamma test cases fail on PPC Macs.  Attached 
are snippets from regrtest runs with trunk and with py3k, both on a G4 ppc 
(32-bit) running OS X 10.5.  Identical failures for trunk (did not try 
py3k) were observed on a G3 ppc with OS X 10.4.

----------
nosy: +ned.deily
Added file: http://bugs.python.org/file15152/gamma-failures.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 07:29:14 2009
From: report at bugs.python.org (Tim Peters)
Date: Sat, 17 Oct 2009 05:29:14 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255757354.35.0.0441735550239.issue3366@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

FYI, mysterious numeric differences on PPC are often due to the C
compiler generated code to use the "fused multiply-add" HW instruction.
 In which case, find a way to turn that off :-)

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 07:36:58 2009
From: report at bugs.python.org (Tom Kuiper)
Date: Sat, 17 Oct 2009 05:36:58 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
Message-ID: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>


New submission from Tom Kuiper <kuiper at jpl.nasa.gov>:

Normal behavior:
>>> from os import path
>>> filename 
= "/home/kuiper/Projects/microdischarges/Observing/2009-09-01/STATS_NP2000_VSR1A.1W1.09-244-193632"
>>> print filename
/home/kuiper/Projects/microdischarges/Observing/2009-09-01/STATS_NP2000_VSR1A.1W1.09-244-193632
>>> print path.basename(filename)
STATS_NP2000_VSR1A.1W1.09-244-193632

Abnormal behavior in class method:
from os import path
...
  def openDataFile(self):
    filename = QFileDialog.getOpenFileName(self, 'Open file','.')
    self.datafile.setTextpath.basename(filename))
...
Traceback (most recent call last):
  File "newWF.py", line 277, in openDataFile
    self.datafile.setText(os.path.basename(filename))
  File "/usr/lib/python2.5/posixpath.py", line 112, in basename
    return split(p)[1]
  File "/usr/lib/python2.5/posixpath.py", line 77, in split
    i = p.rfind('/') + 1
AttributeError: rfind

----------
files: newWF.py
messages: 94167
nosy: kuiper
severity: normal
status: open
title: os.path.basename/split fails
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15153/newWF.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 08:31:52 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Oct 2009 06:31:52 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255761112.62.0.92562903239.issue3366@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

For the record, these OS X installer build scripts (running on 10.5) 
results in these gcc options:

gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -
I/tmp/_py/libraries/usr/local/include -I. -IInclude -I/usr/local/include 
-I/private/tmp/_t/Include -I/private/tmp/_py/_bld/python -c 
/private/tmp/_t/Modules/mathmodule.c -o build/temp.macosx-10.3-fat-
3.2/private/tmp/_t/Modules/mathmodule.o

and:

$ gcc-4.0 --version
powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 08:59:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Oct 2009 06:59:58 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255762798.63.0.546476174575.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  It looks as though the gamma computation itself is fine;  it's the 
accuracy check that's going wrong.

I'm suspecting an endianness issue and/or a struct module bug.

Ned, do you still get these failures with a direct single-architecture 
build on PPC?  Or just for the universal build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 09:07:06 2009
From: report at bugs.python.org (Tim Peters)
Date: Sat, 17 Oct 2009 07:07:06 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255763226.75.0.28096062797.issue3366@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Adding

-mno-fused-madd

would be worth trying.  It usually fixes PPC bugs ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 09:13:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Oct 2009 07:13:23 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255763603.99.0.786697899915.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It was a stupid Mark bug.  I'd missed out a '<' from the struct.unpack 
call that was translating floats into integers, for the purposes of 
computing ulps difference.  Fixed in r75454 (trunk), r75455 (py3k).

Thanks for reporting this, Ned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 09:38:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Oct 2009 07:38:48 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255765128.69.0.26758050474.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, the gamma computation shouldn't be at all fragile, unless I've messed 
up somewhere:  the Lanczos sum is evaluated as a rational function in 
which both numerator and denominator have only positive coefficients, so 
there's little danger of nasty cancellations boosting the relative error.
I'd be surprised if use of fma instructions made more than 1 or 2 ulps 
difference to the result, but I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 13:14:50 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 17 Oct 2009 11:14:50 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
Message-ID: <1255778090.32.0.308260191777.issue7158@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

I think this is not a Python bug, since it concerns PyQt. 

You're passing a QString object to os.path.split(), while the official
documentation wants you pass a Python string.

However, when I tried to run your example, newWF.py, and tried to open a
file from the menu, I got this:

controls.nch: 1024                                                    
Controls Window data shape: (511, 1024)
Data file: None
/home/marco/Programmi/Python-2.6.3/pyconfig.h
Traceback (most recent call last):
  File "issue7158.py", line 277, in openDataFile
    head,tail = os.path.split(filename)
  File "/usr/lib/python2.5/posixpath.py", line 77, in split
    i = p.rfind('/') + 1
AttributeError: 'QString' object has no attribute 'rfind'

Why does this happen? 
`filename` is a QString object. (you can see why here:
http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qfiledialog.html#getOpenFileName
)

So how do you split your filename? I don't know.

I should close this bug.

----------
nosy: +markon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 13:20:26 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 17 Oct 2009 11:20:26 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
Message-ID: <1255778426.3.0.602958986727.issue7158@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

> I should close this bug.

I *would* close this bug. Sorry :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 14:28:11 2009
From: report at bugs.python.org (Tim Peters)
Date: Sat, 17 Oct 2009 12:28:11 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255782491.38.0.526946401055.issue3366@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Mark, you needn't bother:  you found the smoking gun already!  From your
description, I agree it would be very surprising if FMA made a
significant difference in the absence of catastrophic cancellation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:09:20 2009
From: report at bugs.python.org (Tom Kuiper)
Date: Sat, 17 Oct 2009 14:09:20 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255778090.32.0.308260191777.issue7158@psf.upfronthosting.co.za>
Message-ID: <4AD9D009.5060401@jpl.nasa.gov>


Tom Kuiper <kuiper at jpl.nasa.gov> added the comment:

That's a good point, Marco.  I'd forgotten about the distinction.  
Converting 'filename' to a Python string with 'str()' fixed the problem.
> However, when I tried to run your example, newWF.py, and tried to open a
> file from the menu, I got this:
>
> controls.nch: 1024                                                    
> Controls Window data shape: (511, 1024)
> Data file: None
> /home/marco/Programmi/Python-2.6.3/pyconfig.h
> Traceback (most recent call last):
>   File "issue7158.py", line 277, in openDataFile
>     head,tail = os.path.split(filename)
>   File "/usr/lib/python2.5/posixpath.py", line 77, in split
>     i = p.rfind('/') + 1
> AttributeError: 'QString' object has no attribute 'rfind'
>   
I'm sorry about the confusion.  In the file I attached I had tried using 
'os.path.split()', with no luck.
> Why does this happen? 
> `filename` is a QString object. (you can see why here:
> http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qfiledialog.html#getOpenFileName
> )
>
> So how do you split your filename? I don't know.
>   
Python's 'split()' works, like this:
    basename = filename.split('/')[-1]
    self.datafile.setText(basename)
Also, with less code,
    self.datafile.setText(os.path.basename(str(filename)))
> I should close this bug.
>   
Yes.  Please do.  I guess it's useful though to have our e-mail exchange 
on record for anyone else who stumbles over the Python string vs QString 
distinction.

Thanks and regards

Tom
> ----------
> nosy: +markon
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7158>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:18:49 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 17 Oct 2009 14:18:49 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
Message-ID: <1255789129.19.0.351405252987.issue7158@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

I cannot close this bug, ahah :)

BTW: I'm happy you solved this bug.
Bye.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:21:20 2009
From: report at bugs.python.org (Tom Kuiper)
Date: Sat, 17 Oct 2009 14:21:20 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255789129.19.0.351405252987.issue7158@psf.upfronthosting.co.za>
Message-ID: <4AD9D2DA.30109@jpl.nasa.gov>


Tom Kuiper <kuiper at jpl.nasa.gov> added the comment:

Do I have to do that?  I've never used the Python bug tracking system 
before.
> BTW: I'm happy you solved this bug.
>   
I guess we could consume a few beers over whether it's a bug or not.

Cheers

Tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:21:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2009 14:21:51 +0000
Subject: [issue7158] os.path.basename/split fails
In-Reply-To: <1255757817.87.0.79246409428.issue7158@psf.upfronthosting.co.za>
Message-ID: <1255789311.57.0.685390830476.issue7158@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7158>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:47:32 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 17 Oct 2009 14:47:32 +0000
Subject: [issue1646838] os.path,
	%HOME% set: realpath contradicts expanduser on '~'
Message-ID: <1255790852.83.0.586155487299.issue1646838@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


----------
nosy: +markon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646838>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:48:48 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 17 Oct 2009 14:48:48 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1255790928.62.0.540457516588.issue6975@psf.upfronthosting.co.za>


Changes by Marco Buccini <marcusbu at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sat Oct 17 17:15:25 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 17 Oct 2009 15:15:25 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1255792525.17.0.933244336721.issue6975@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

I've just found a similar bug:
http://bugs.python.org/issue1646838

However, does os.path.realpath's behavior have to be as the one
specified by the POSIX standard (
http://www.kernel.org/doc/man-pages/online/pages/man3/realpath.3.html )?
If we wanted to follow the standard, we should break the
retro-compatibility, since we should raise an exception in the case the
path passed as argument doesn't exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sat Oct 17 17:32:39 2009
From: report at bugs.python.org (Brad Olson)
Date: Sat, 17 Oct 2009 15:32:39 +0000
Subject: [issue7159] Urllib2 authentication memory.
In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
Message-ID: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>


New submission from Brad Olson <brado at movedbylight.com>:

For each request requiring HTTP authentication, urllib2 submits the
request without authentication, receives the server's 401
error/challenge, then re-submits the request with authentication.

This is compliant behavior. The problem comes in that urllib2 repeats
this for every ensuing request to the same namespace.

At times this is just an inefficiency--every request gets sent twice,
often with POST data (which can be sizeable).

Sometimes, especially with large POST bodies, this causes a connection
failure.

(Mercurial suffers greatly from this (and I have suggested workaround to
that team.)

This isn't non-compliant behavior, but RFC2617 (sections 2, 3.3)
suggests that once an HTTP client authenticates, it pre-emptively send
authentication with ensuing requests.

More analysis and fix suggestions at
bitbucket.org/bradobro/liquidhg/wiki/Home.

----------
components: Library (Lib)
messages: 94180
nosy: bradobro
severity: normal
status: open
title: Urllib2 authentication memory.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7159>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:31:04 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Sat, 17 Oct 2009 16:31:04 +0000
Subject: [issue7160] Crash when returning a 64-bit char pointer in Python
	2.6.3 ctypes
In-Reply-To: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
Message-ID: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>


New submission from Michael J. Fromberger <michael.j.fromberger at gmail.com>:

A segmentation fault is generated in _ctypes.so when calling a function that returns a char pointer on a system 
with 64-bit pointer types.  The attached crash dump is from a Python 2.6.3 built from MacPorts ("port install 
python26 +no_tkinter"), but the same behaviour occurs with the Python 2.6.1 installed by Apple.

To reproduce, build the attached sample program ("testlib.c"):

% gcc -Wall -c testlib.o
% ld -dylib -o testlib.so testlib.o

Then, in Python:

# Common setup for each of the cases below.
>>> from ctypes import *
>>> lib = CDLL('testlib.so')

# Case 1: Integer return value (no crash).
>>> get_value = CFUNCTYPE(c_int)(lib.get_value)
>>> get_value()
12345

# Case 2: Pointer argument value (no crash).
>>> buf = create_string_buffer(256)
>>> copy_message = CFUNCTYPE(None, c_char_p)(lib.copy_message)
>>> copy_message(buf)

# Case 3: Pointer return value (crash).
>>> get_message = CFUNCTYPE(c_char_p)(lib.get_message)
>>> get_message()
Segmentation fault

-- System information:

% uname -a
MacOS 10.6.1
Darwin gorion.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-
1456.1.25~1/RELEASE_I386 i386

% python
Python 2.6.3 (r263:75183, Oct 17 2009, 01:49:30) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin

% gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)

----------
assignee: theller
components: ctypes
files: testlib.c
messages: 94181
nosy: creachadair, theller
severity: normal
status: open
title: Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15154/testlib.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7160>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:31:49 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Sat, 17 Oct 2009 16:31:49 +0000
Subject: [issue7160] Crash when returning a 64-bit char pointer in Python
	2.6.3 ctypes
In-Reply-To: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
Message-ID: <1255797109.67.0.457128272052.issue7160@psf.upfronthosting.co.za>


Changes by Michael J. Fromberger <michael.j.fromberger at gmail.com>:


Added file: http://bugs.python.org/file15155/crash-report.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7160>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:47:42 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Sat, 17 Oct 2009 16:47:42 +0000
Subject: [issue7160] Crash when returning a 64-bit char pointer in Python
	2.6.3 ctypes
In-Reply-To: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
Message-ID: <1255798062.64.0.0136802912343.issue7160@psf.upfronthosting.co.za>


Michael J. Fromberger <michael.j.fromberger at gmail.com> added the comment:

I believe this error occurs because a pointer value is being truncated to 
32 bits.  The exception code is

KERN_INVALID_ADDRESS at 0x00000000002fe020

If you add a diagnostic printout to the body of get_message(), you will 
see that its return value is 0x1002fe020, so in other words, the high-
order word 0x00000001 is being discarded somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7160>
_______________________________________

From report at bugs.python.org  Sat Oct 17 19:10:27 2009
From: report at bugs.python.org (Trundle)
Date: Sat, 17 Oct 2009 17:10:27 +0000
Subject: [issue7160] Crash when returning a 64-bit char pointer in Python
	2.6.3 ctypes
In-Reply-To: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
Message-ID: <1255799427.7.0.452876793669.issue7160@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

You are using `CFUNCTYPE` wrong. `CFUNCTYPE` returns a type which will 
take a *Python function* (or an address of a function as integer). You 
provide `lib.get_message` as Python function, which is a wrapper object 
for the C function. By default, ctypes assumes an int as return type for 
C functions. On your platform, the size of an int is not the same as the 
size of a pointer. Therefore, the return value is truncated. You call 
the CFUNCTION which then calls `lib.get_message` which returns the 
truncated pointer as integer and then ctypes tries to make a `c_char_p` 
out of the integer which segfaults because it's truncated.

I think what you are really looking for is ``lib.get_message.restype = 
c_char_p``.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7160>
_______________________________________

From report at bugs.python.org  Sat Oct 17 20:01:18 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 17 Oct 2009 18:01:18 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1255802478.09.0.103454461279.issue6952@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Here is my 1st patch to allow const char * and const Py_UNICODE *
It is agsinst http://svn.python.org/projects/python/trunk.

What I have attempted to do is stop the public API of python needing
char * or Py_UNICODE * where the API clearly does not need to modify
the argument. I have only modified internal API where its necessary
to provide a public const API.

Please give feedback and let me know if you wish me raise anything
with python dev.

I'm happy to produce a 3.2 version of the patch after the 2.7 version
is acceptable.

Barry

----------
keywords: +patch
Added file: http://bugs.python.org/file15156/const_api_r75468.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sat Oct 17 21:25:50 2009
From: report at bugs.python.org (Trundle)
Date: Sat, 17 Oct 2009 19:25:50 +0000
Subject: [issue7161] raise of SyntaxError in codeop was ported incorrectly to
	Py3
In-Reply-To: <1255807550.69.0.197783974238.issue7161@psf.upfronthosting.co.za>
Message-ID: <1255807550.69.0.197783974238.issue7161@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

The original lines in Lib/codeop.py under Python 2.6:

raise SyntaxError, err1

Those lines were ported to Python 3 as:

raise SyntaxError(err1)

Which is wrong because `err1` is in both cases an instance of 
`SyntaxError`. Quote from the language reference: "If the first object 
is a class, it becomes the type of the exception. The second object is 
used to determine the exception value: If it is an instance of the 
class, the instance becomes the exception value." Therefore, the correct 
translation of that code is: "raise err1".

The attached patch fixes the issue.

----------
components: Library (Lib)
files: codeop_raise_syntaxerror.patch
keywords: patch
messages: 94185
nosy: Trundle
severity: normal
status: open
title: raise of SyntaxError in codeop was ported incorrectly to Py3
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15157/codeop_raise_syntaxerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7161>
_______________________________________

From report at bugs.python.org  Sat Oct 17 21:29:29 2009
From: report at bugs.python.org (egreen)
Date: Sat, 17 Oct 2009 19:29:29 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255807769.69.0.16683215949.issue7080@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

I've added the tests.

I found that on Windows, strxfrm has been unavailable in py3k since
r61306, because of an omission in PC/pyconfig.h.  (cf. patch)

In determining whether I should first test for the existence of strcoll
(or strxfrm) in the locale module, as was done in TestMiscellaneous, I
found this is no longer needed in py3k since r61339.  (cf. patch)  (In
python2 such checks are still necessary.)

----------
Added file: http://bugs.python.org/file15158/strxfrm_fixes_and_collation_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Sat Oct 17 22:30:21 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 17 Oct 2009 20:30:21 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255811421.13.0.883211156838.issue7149@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Ronald, please apply asap.  This is the last thing I'm waiting on before
I tag 2.6.4rc2.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Sat Oct 17 22:50:41 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 17 Oct 2009 20:50:41 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255812641.73.0.483928457756.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

A patch including tests and documentation is now in attachment.
The test TLS server is very similar to pyftpdlib's I draw on:
http://code.google.com/p/pyftpdlib/source/browse/trunk/demo/tls_ftpd.py
I wasn't able to "compile" the documentation so I'm not 100% sure it looks 
perfectly.
Test suite run successfully on Windows XP, Ubuntu 9.04 and FreeBSD 7.1.

----------
nosy: +josiah.carlson, josiahcarlson
Added file: http://bugs.python.org/file15159/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Sat Oct 17 22:52:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Oct 2009 20:52:57 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1255812777.75.0.71541183444.issue6952@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Without looking into the details: the places where you cast-away
constness look wrong. Either the parameter shouldn't have been declared
const, or the target of the assignment needs to be converted to const,
too. If the cast is really legitimite, a comment needs to justify it
(but then, I think I would still prefer not to change the parameter to
const).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sat Oct 17 23:29:39 2009
From: report at bugs.python.org (Joe Amenta)
Date: Sat, 17 Oct 2009 21:29:39 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

Step to reproduce:

$ echo 'file("/some/file")' | python `which 2to3` -

(replace python with whichever python executable version you wish to
use, e.g. ~/python-trunk/python or /usr/local/bin/python3.2 )

Expected result:
Anything referring to the fact that the "file" type no longer exists in
python 3.x, whether it be a warning or a refactoring.

Actual result:
RefactoringTool: No files need to be modified.

Just a report for now, I don't have the time to write a patch.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94190
nosy: joe.amenta
severity: normal
status: open
title: 2to3 does not convert __builtins__.file
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Sun Oct 18 00:38:03 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2009 22:38:03 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

IDLE
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32

>>> import sys
>>> sys.stdout.write('abc')
abc

whereas

Command Window
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32

>>> import sys
>>> sys.stdout.write('abc')
abc3

----------
components: IDLE
messages: 94191
nosy: tjreedy
severity: normal
status: open
title: IDLE suppresses sys.stdout.write() return value
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Sun Oct 18 00:48:58 2009
From: report at bugs.python.org (kristall)
Date: Sat, 17 Oct 2009 22:48:58 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1255819738.89.0.356077218319.issue1160@psf.upfronthosting.co.za>


kristall <kristall at c-base.org> added the comment:

aloha,

I also use large RE's. re.compile() worked fine under python2.6 (OS
ubuntu-linux). After moving the code to python3.0 I get the same error
as ostkamp did. Under 3.1 also. Under 3.1 I tried to the fix that
ostkamp described (setting 'short' to 'long' in Modules/sre.h) and
rebuild python, but still the error occurs. I want to change to 3.x
since my variables contain german text with Umlauten (?, ?, ? etc.) and
its pain to work with unicode under 2.x. Is there anything else I can
try, or is there a planned date when this bug will be fixed. I am
thankful in advance for any help.

kristall

----------
nosy: +kristall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
_______________________________________

From report at bugs.python.org  Sun Oct 18 01:43:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Oct 2009 23:43:21 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255823001.98.0.554137518559.issue7153@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Here?s a summary of my research so far (including discussion with other
programmers, a Google code search, discussion on #python-dev on IRC, and
comparing the proposal to other APIs with start-arguments such as sum(),
reduce(), and enumerate()):

1. Showed several examples to other programmers and found that they did
not immediately get what the start argument was trying to do.  Was a
start argument the same as:

 reduce(max, seq, 0)     # zero when empty and never less than zero
 max(seq) if seq else 0  # zero when empty (only works for sequences)
 max(chain([0], seq)     # zero when empty and never less than zero

2. There is an issue of API complexity.  Even if a feature is useful and
clear, it may not be a good idea when the API of a function is already
complex.  In the case of min()/max(), we already have special handling
for one argument (treated as an iterator) versus no arguments (treated
an error versus multiple arguments (treated as an input sequence of
values).  We also have a key= argument.  Taken together, the min/max
functions already have a lot of features.

3.Beyond the complexity of having too many features in a function that
should be simple, there is also an issue of how those features would
interact:

 min(iterable, key=f, start=x)  # is the default value x or f(x)?
 min(start=x)          # should this be allowed?
 min(*args, start=x)   # if so, what is behavior when len(args)==0 or 1
or 2?

4. The argument about reduce(max, seq, 0) being confusing to
non-functional programmers isn?t persuasive since perfectly clear
(though multi-line) exception-catching or size-checking imperative forms
can be written, or one can can simply factor-out any recurring
expressions if they seem awkward or confusing:

    def max_or_zero(iterable):
        'Return zero if the iterable is empty or max(0, max(iterable))
otherwise'
        return functools.reduce(max, iterable, 0)

5. In the case of sequences, it can be clearer to write:

 max(seq) if seq else 0  
 max(seq + [0])     # or use itertools.chain()

6. A code search showed that max() is mostly used in a two-argument
form.  When it does get used with iterables, it doesn't seem common to
trap ValueErrors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Sun Oct 18 02:29:08 2009
From: report at bugs.python.org (Ehsan Amiri)
Date: Sun, 18 Oct 2009 00:29:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1255825748.53.0.240974255433.issue7092@psf.upfronthosting.co.za>


Changes by Ehsan Amiri <ehsanamiri at gmail.com>:


----------
nosy: +esam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Oct 18 02:33:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Oct 2009 00:33:27 +0000
Subject: [issue7161] raise of SyntaxError in codeop was ported incorrectly to
	Py3
In-Reply-To: <1255807550.69.0.197783974238.issue7161@psf.upfronthosting.co.za>
Message-ID: <1255826007.82.0.455812764797.issue7161@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r75472.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7161>
_______________________________________

From report at bugs.python.org  Sun Oct 18 03:14:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Oct 2009 01:14:24 +0000
Subject: [issue7164] pickle test failure after test_imp/test_import
	(_make_stat_result is not the same object as os._make_stat_result)
In-Reply-To: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za>
Message-ID: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

After r75467, which changed test_imp and test_import to use CleanImport,
the various pickle tests fail (all in the same common test, I believe).
 The error looks like this:

Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/pickletester.py", line 623,
in test_structseq
    s = self.dumps(t, proto)
  File "/home/rdmurray/python/trunk/Lib/test/test_pickle.py", line 33,
in dumps
    p.dump(arg)
  File "/home/rdmurray/python/trunk/Lib/pickle.py", line 224, in dump
    self.save(obj)
  File "/home/rdmurray/python/trunk/Lib/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/home/rdmurray/python/trunk/Lib/pickle.py", line 400, in save_reduce
    save(func)
  File "/home/rdmurray/python/trunk/Lib/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/home/rdmurray/python/trunk/Lib/pickle.py", line 753, in save_global
    (obj, module, name))
PicklingError: Can't pickle <function _make_stat_result at 0xb7a09494>:
it's not the same object as os._make_stat_result

I don't have enough pickle-foo to understand what it is trying to do
here or what about CleanImport is messing it up.

----------
components: Tests
messages: 94195
nosy: brett.cannon, ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: pickle test failure after test_imp/test_import (_make_stat_result is not the same object as os._make_stat_result)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7164>
_______________________________________

From report at bugs.python.org  Sun Oct 18 04:01:55 2009
From: report at bugs.python.org (paul rubin)
Date: Sun, 18 Oct 2009 02:01:55 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255831315.6.0.0910179170454.issue7153@psf.upfronthosting.co.za>


paul rubin <phr at users.sourceforge.net> added the comment:

1. Yes, the idea is to figure out the best solution and go with it (or
decide to do nothing).  That many possibilities exist just points to the
need for experience and wisdom in identifying the best choice ("one and
preferably only one").  One of the attractive points about Python is it
comes with so many such decisions already wisely made.  The design
wisdom embodied in Python is almost like a useful software library in
its own right.  So the presence of multiple choices should be seen as an
invitation to resolve the issue, not a flag to keep it unresolved.

2. I agree that the multi-arg and iterator API's should have been done
as separate functions (or denoted through a keyword arg), but what we
have isn't too bad, and it's what we have.

3.  min(iterable, key=f, start=x) should obviously default to the same
thing as min([x], key=f).  min(*args, start=x) should only be allowed
when len(args)==1, since the start arg is restricted to the case of
minimum over an iterator.  min(start=x) should not be allowed.

4. I'm in general unpersuaded by the argument that a stdlib function
isn't worth having because the same thing can be done by bloating up the
user code.  Python code should be concise, which means using the stdlib
in preference to writing more user-defined functions that the next
maintainer has to figure out, and which may have their own bugs and
unhandled edge cases.  For stdlib design, it's mostly a matter of
deciding whether a construction occurs often enough to write a re-usable
function for.  In this case it wouldn't have occurred to me to write any
of those suggested versions, instead of writing reduce(max, iterator, 0)
with an explanatory comment.  But even the observation that "reduce"
made me bloat up the comments in the code, rather than the code itself,
was enough to get me to suggest adding the initial arg.

5. I don't think it's good to rely on bool(seq) or len(seq) to be
available if there's a simple construction (like here) that works for
arbitrary iterables.  It's better to handle the general case.  I hadn't
even realized til just now that "sequence" and "iterable" didn't mean
the same thing.

6. Yes, I know it's not common to trap ValueErrors when using max with
iterables.  I wrote code without such traps myself and then got bitten
by unhandled exceptions when some of those iterables turned out to be
empty (hence my "reduce" hack).  It wouldn't surprise me if lots more
such code out there is similarly buggy.  I think it's good to make
bug-avoiding mechanisms obvious and convenient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Sun Oct 18 04:02:12 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Oct 2009 02:02:12 +0000
Subject: [issue7155] urllib2 and python 3 urllib do not document default use
	of system proxy configuration
In-Reply-To: <1255736727.77.0.830573740037.issue7155@psf.upfronthosting.co.za>
Message-ID: <1255831332.32.0.0575286063798.issue7155@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the comments.

Fixed and committed the changes trunk - 75478.
and merged into
release26-maint - 75479.
py3k - r75476
release31-maint - r75477

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7155>
_______________________________________

From report at bugs.python.org  Sun Oct 18 04:05:21 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Oct 2009 02:05:21 +0000
Subject: [issue7159] Urllib2 authentication memory.
In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
Message-ID: <1255831522.0.0.478880711264.issue7159@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7159>
_______________________________________

From report at bugs.python.org  Sun Oct 18 04:07:12 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Oct 2009 02:07:12 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1255831632.96.0.812526788142.issue5625@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Sun Oct 18 04:21:04 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Oct 2009 02:21:04 +0000
Subject: [issue5475] urllib2.getproxies not documented
In-Reply-To: <1236766495.94.0.773728136477.issue5475@psf.upfronthosting.co.za>
Message-ID: <1255832464.58.0.903558387656.issue5475@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

getproxies is urllib one of the many helper functions that is not
documented in the Documentation files.

I am not sure of a good resolution for this (leave it as such/Document
it/ make it private). I shall look into the test coverage,usage of the
function and decide.

----------
assignee: georg.brandl -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5475>
_______________________________________

From report at bugs.python.org  Sun Oct 18 05:00:12 2009
From: report at bugs.python.org (Sylwester Warecki)
Date: Sun, 18 Oct 2009 03:00:12 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1255792525.17.0.933244336721.issue6975@psf.upfronthosting.co.za>
Message-ID: <4ADA84D8.8060000@cox.net>


Sylwester Warecki <swarecki at cox.net> added the comment:

Marco,

Thanks for looking deeper into it.
I would like to check the solution ASAP.
We have really crazy dir structure which can catch a lot of
the unexpected problems with paths, links, circular links etc.

Should I expect the new version to generate the exception
as you suggested?

Best Regards,
    Sywlester Warecki

Marco Buccini wrote:
> Marco Buccini <marcusbu at gmail.com> added the comment:
>
> I've just found a similar bug:
> http://bugs.python.org/issue1646838
>
> However, does os.path.realpath's behavior have to be as the one
> specified by the POSIX standard (
> http://www.kernel.org/doc/man-pages/online/pages/man3/realpath.3.html )?
> If we wanted to follow the standard, we should break the
> retro-compatibility, since we should raise an exception in the case the
> path passed as argument doesn't exist.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6975>
> _______________________________________
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sun Oct 18 06:10:19 2009
From: report at bugs.python.org (Joe Amenta)
Date: Sun, 18 Oct 2009 04:10:19 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1255839019.24.0.889887766126.issue7162@psf.upfronthosting.co.za>


Changes by Joe Amenta <amentajo at msu.edu>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Sun Oct 18 07:16:33 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Oct 2009 05:16:33 +0000
Subject: [issue7164] pickle test failure after test_imp/test_import
	(_make_stat_result is not the same object as os._make_stat_result)
In-Reply-To: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za>
Message-ID: <1255842993.12.0.324544521204.issue7164@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Must have missed running the full test suite before checking that one
in. Whoops...

Anyway, the culprit is a couple of copy_reg calls that the os module
runs on import to register pickle support methods. CleanImport's
simplistic approach to reversion leaves the replacement handlers
registered even after the original os module has been restored, leading
to copy_reg complaining when you attempt to use the registered pickle
handlers.

I'll narrow the scope to just reverting os.environ and otherwise leave
the new os module in place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7164>
_______________________________________

From report at bugs.python.org  Sun Oct 18 07:39:55 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Oct 2009 05:39:55 +0000
Subject: [issue7164] pickle test failure after test_imp/test_import
	(_make_stat_result is not the same object as os._make_stat_result)
In-Reply-To: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za>
Message-ID: <1255844395.84.0.120863580974.issue7164@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Should be OK again as of r75481.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7164>
_______________________________________

From report at bugs.python.org  Sun Oct 18 07:56:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Oct 2009 05:56:14 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1255845374.35.0.948172683476.issue4120@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's a procedure for testing this patch (please be as precise as
possible)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:10:23 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Oct 2009 07:10:23 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255849823.04.0.750671536593.issue7149@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r75483 (2.6), 75482 (trunk)

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:10:31 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Oct 2009 07:10:31 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255849831.24.0.604006237361.issue7149@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:11:04 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Oct 2009 07:11:04 +0000
Subject: [issue7044] urllib.urlopen crashes when used on Mac OS 10.6.1 through
	a proxy
In-Reply-To: <1254540655.1.0.243210284724.issue7044@psf.upfronthosting.co.za>
Message-ID: <1255849864.35.0.824532501738.issue7044@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r75482 (trunk) and r75483 (2.6)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7044>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:14:42 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Oct 2009 07:14:42 +0000
Subject: [issue7107] Missing uninstallation instructions for mac
In-Reply-To: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
Message-ID: <1255850082.22.0.0868244686554.issue7107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The root cause for this issue is Apple's broken installer system: Apple 
does have a package installer, but does not provide tools to uninstall 
packages. 

I'm reluctant to provide an uninstaller as part of the Python project, 
such a tool would require serious testing to ensure that it doesn't 
accidentally remove too much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7107>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:18:30 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Oct 2009 07:18:30 +0000
Subject: [issue7102] Problems building pyhton from source on Snow Leopard (Mac
	OS X 10.6)
In-Reply-To: <1255259767.14.0.58470388627.issue7102@psf.upfronthosting.co.za>
Message-ID: <1255850310.83.0.444103522582.issue7102@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The fixes will be in 3.1.2 and 3.2 when those are released. I don't know 
when that it though, until than you can build the version in the 
repository.

The 3.1 branch tends to be stable, developers are supposed to only port 
bugfixes to this branch, new development goes into 3.2.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7102>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:49:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Oct 2009 07:49:09 +0000
Subject: [issue7147] Remove WITHOUT_COMPLEX from 3.x trunk
In-Reply-To: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>
Message-ID: <1255852149.83.0.746532052359.issue7147@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Skip, I think you could just check this in.  (Or I can do it if you'd 
prefer.)

----------
assignee:  -> skip.montanaro
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7147>
_______________________________________

From report at bugs.python.org  Sun Oct 18 10:13:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Oct 2009 08:13:16 +0000
Subject: [issue7128] cPickle looking for non-existent package copyreg
In-Reply-To: <1255536754.55.0.971036296539.issue7128@psf.upfronthosting.co.za>
Message-ID: <1255853596.28.0.617702734674.issue7128@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Probably the whole of r63042 should be undone.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7128>
_______________________________________

From report at bugs.python.org  Sun Oct 18 11:07:23 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sun, 18 Oct 2009 09:07:23 +0000
Subject: [issue6975] symlinks incorrectly resolved on Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1255856843.14.0.672184365618.issue6975@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

>Thanks for looking deeper into it.
>I would like to check the solution ASAP.
>We have really crazy dir structure which can catch a lot of
>the unexpected problems with paths, links, circular links etc.

Oh well, so you can see if the patch works correctly on all paths :)
 
>Should I expect the new version to generate the exception
>as you suggested?

 
Unfortunately I'm not God, so I cannot change the "code" of the current
implementation of os.path.realpath (raising an OSError exception)
without breaking any existing code. 
So, consider using the current implementation of os.path.realpath ;)
If you experience other strange behaviors, then open a new bug report.

Bye!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sun Oct 18 12:27:28 2009
From: report at bugs.python.org (strank)
Date: Sun, 18 Oct 2009 10:27:28 +0000
Subject: [issue1646838] os.path,
	%HOME% set: realpath contradicts expanduser on '~'
Message-ID: <1255861648.92.0.506185700135.issue1646838@psf.upfronthosting.co.za>


strank <strank at strank.info> added the comment:

I agree with the 'test needed' stage, but for that, the intended
behaviour should be decided on first. A quick test for checking current
behaviour::

  pythonX.Y -c 'import os; p = os.path; print (os.environ["HOME"],
p.realpath("~"), p.expanduser("~"), p.normpath("~"))'

Run both, with and without HOME set (or set to something unusual).

Current result on Linux for both 2.5 and 2.6::

  ('/home/rank', '/home/rank/~', '/home/rank', '~')

on Mac OS for 2.5, 2.6 and 3.1::

  ('/Users/rank', '/Users/rank/~', '/Users/rank', '~')

(for 3.1 it's not a tuple of course).

Cannot test on Windows at the moment, but I think there's already
something wrong going on here :-).

Adding Macintosh and tested python version tags (there's no Unix tag?).

cheers

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren, strank
versions: +Python 2.5, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646838>
_______________________________________

From report at bugs.python.org  Sun Oct 18 13:06:09 2009
From: report at bugs.python.org (Marco Buccini)
Date: Sun, 18 Oct 2009 11:06:09 +0000
Subject: [issue1646838] os.path,
	%HOME% set: realpath contradicts expanduser on '~'
Message-ID: <1255863969.82.0.355299494191.issue1646838@psf.upfronthosting.co.za>


Marco Buccini <marcusbu at gmail.com> added the comment:

If we decide to follow paths as '~' it means that we want to follow the
POSIX standard.

Infact, it doesn't make sense calling os.path.realpath as follow:
>>> import os
>>> os.getcwd()
'/home/marco/Desktop'
>>> os.path.realpath('~')
To get something like:
'/home/marco/Desktop/$HOME' 
that would expand as:
'/home/marco/Desktop/home/marco' 

At this point we should implement a new os.path.realpath to check if the
path passed as argument exists [ See ERRORS section:
http://www.opengroup.org/onlinepubs/9699919799/functions/realpath.html
]. But this means that in the worst case, we would raise an Exception
(i.e., OSError).

As I've said [ here: http://bugs.python.org/issue6975 ] we cannot
implement a POSIX compliant os.path.realpath, since it would break with
existing code. You understand that a change like this is an API change. 

I think Python will have an own `realpath` version, not fully
POSIX-compliant, unluckly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646838>
_______________________________________

From report at bugs.python.org  Sun Oct 18 13:12:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Oct 2009 11:12:01 +0000
Subject: [issue1646838] os.path,
	%HOME% set: realpath contradicts expanduser on '~'
Message-ID: <1255864321.19.0.510234730833.issue1646838@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646838>
_______________________________________

From report at bugs.python.org  Sun Oct 18 13:24:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Oct 2009 11:24:32 +0000
Subject: [issue1646838] os.path,
	%HOME% set: realpath contradicts expanduser on '~'
Message-ID: <1255865072.8.0.456927679591.issue1646838@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee: ronaldoussoren -> 
components:  -Macintosh, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646838>
_______________________________________

From report at bugs.python.org  Sun Oct 18 14:40:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Oct 2009 12:40:49 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The xmlrpc tests were changed to use a StringIO object instead of a
temporary file (this change reflects the corresponding change made on
the 2.x trunk).

The tests then started failing, since xmlrpc.server assumes sys.stdout
will provide the buffer attribute, which is not a valid assumption. From
the io.TestIOBase documentation:

buffer
    The underlying binary buffer (a BufferedIOBase instance) that
TextIOBase deals with. This is not part of the TextIOBase API and may
not exist on some implementations.

Assuming this attribute exists is a bug in xmlrpc.server that should be
fixed.

----------
components: Library (Lib)
messages: 94212
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: xmlrpc.server assumes sys.stdout will have a buffer attribute
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Sun Oct 18 16:26:32 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 18 Oct 2009 14:26:32 +0000
Subject: [issue7147] Remove WITHOUT_COMPLEX from 3.x trunk
In-Reply-To: <1255650304.9.0.743144101896.issue7147@psf.upfronthosting.co.za>
Message-ID: <1255875992.1.0.991970366969.issue7147@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Committed revision 75495.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7147>
_______________________________________

From report at bugs.python.org  Sun Oct 18 17:18:45 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 18 Oct 2009 15:18:45 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1255879125.44.0.193745924143.issue6952@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I was trying to avoid changing the const ness of output parameters.
Given the advice not to go mad on putting const everywhere.

1) I can comment the casts to maintain this goal.
2) Or change the output paramter const ness.

Given your feedback I'm guessing you want me to go further with 
the use of const and do (2).

Barry

----------
components: +Extension Modules -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:07:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Oct 2009 17:07:54 +0000
Subject: [issue7127] regrtest -j fails when tests write to stderr
In-Reply-To: <1255536423.67.0.1834189118.issue7127@psf.upfronthosting.co.za>
Message-ID: <1255885674.06.0.0500559290535.issue7127@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Look like I forgot that I opened this issue, and opened a new one
with the patch.  Closing this one in favor of the one with the patch.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> regrtest -j sometimes fails if output gets written to stderr by a test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7127>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:12:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Oct 2009 17:12:38 +0000
Subject: [issue7151] regrtest -j sometimes fails if output gets written to
	stderr by a test
In-Reply-To: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
Message-ID: <1255885958.39.0.917161784068.issue7151@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Updated patch that moves the print of the test name into the output that
gets put into the queue so that all output from a test stays together.

----------
assignee: pitrou -> nobody
nosy: +ezio.melotti, nobody
Added file: http://bugs.python.org/file15160/regrtestj3stderr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7151>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:23:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Oct 2009 17:23:00 +0000
Subject: [issue7151] regrtest -j sometimes fails if output gets written to
	stderr by a test
In-Reply-To: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
Message-ID: <1255886580.33.0.166033025201.issue7151@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file15148/regrtestj3stderr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7151>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:42:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Oct 2009 17:42:08 +0000
Subject: [issue1646838] os.path,
	%HOME% set: realpath contradicts expanduser on '~'
Message-ID: <1255887728.64.0.222566181506.issue1646838@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

realpath is only supposed to return an absolute pathname, resolving '.',
'..' and symlinks. It's not its duty to expand '~', therefore in your
example

> In [3]: path.realpath('~')
> Out[3]: 'C:\\Dokumente und Einstellungen\\wrstl\\~'

the '~' is seen as a normal file and the cwd is used to create the
absolute path to it (on Windows realpath is the same as abspath, on
Linux realpath calls abspath when there's nothing to resolve, so the
result is the same -- i.e. cwd + filename).


realpath needs better tests and documentation though, but this can be
addressed in #6975, so I'm closing this.

----------
assignee:  -> ezio.melotti
resolution:  -> works for me
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646838>
_______________________________________

From report at bugs.python.org  Sun Oct 18 20:19:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Oct 2009 18:19:10 +0000
Subject: [issue1779233] PyThreadState_SetAsyncExc and the main thread
Message-ID: <1255889950.86.0.40457131048.issue1779233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following works (2.6 and trunk):

import ctypes, thread
ctypes.pythonapi.PyThreadState_SetAsyncExc(
    ctypes.c_long(thread.get_ident()),
    ctypes.py_object(ZeroDivisionError))
for i in range(1000): pass


The thing to remember is that PyThreadState_SetAsyncExc() is
asynchronous and doesn't guarantee that the exception will be raised
timely (that's why I added a small busy loop above).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1779233>
_______________________________________

From report at bugs.python.org  Sun Oct 18 20:22:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Oct 2009 18:22:49 +0000
Subject: [issue1779233] PyThreadState_SetAsyncExc and the main thread
Message-ID: <1255890169.38.0.347700432762.issue1779233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've added a test for it in r75499. Now closing this bug, still the
function actually works :-)

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1779233>
_______________________________________

From report at bugs.python.org  Sun Oct 18 21:26:11 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Oct 2009 19:26:11 +0000
Subject: [issue7153] add "start" arg to max and min functions
In-Reply-To: <1255721043.52.0.906494418992.issue7153@psf.upfronthosting.co.za>
Message-ID: <1255893971.09.0.68236209938.issue7153@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the thoughtful reply.  To give the idea another chance,
today, I showed a code example to another experienced programmer.

"What does this function return?
   max([-2, 5], start=0)
"

The person had a hard time making any sense of it.  Perhaps the start
argument was an index, or starting position, or a ceiling, or a floor.

I'm rejecting the feature request for several reasons:

* the code sample doesn't have obvious meaning to experienced programmers

* the API of the min/max functions is already too complex -- the
language needs to be easy to learn and remember

* the start keyword argument doesn't interact well with the other
features (such as the key argument or positional arguments).  Mark
questioned whether the key function would apply to the start value (any
answer is arbitrary because either could work).  Also, there was a
question of how it would work with *args (does it change the case with
zero arguments as it does for the iterator case).  When the choice of
semantics are arbitrary, it is better not to guess and instead have the
coder explicitly say what is supposed to happen.

* it isn't really needed, there are several existing ways to create the
same effect. 

* the meaning of "start" is ambiguous and arbitrary (is it a default
value for an empty input or it is like adding an extra value to the
input sequence).  We could pick one of the two meanings but that doesn't
help a coder or code reviewer remember which meaning was correct.  To
prevent bugs, it is better for the code to explicitly spell-out how the
corner case is to be handled.

* in mathematical notation, I see the corner cases being handled by
piecewise functions (if seq is empty, value is this, else compute
min/max) instead of the notation trying to override the simple meaning
of min/max.

* I haven't found precendents in any other language.  Even if there
were, we would still have the problem of too many features being loaded
onto Python's min/max and the unclear semantics of how those features
would interact.

Thank you for the feature request.  Sorry, this one didn't pan out.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7153>
_______________________________________

From report at bugs.python.org  Sun Oct 18 21:29:47 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 18 Oct 2009 19:29:47 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1255894187.24.0.804609270139.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

There are two levels of testing.

First, on a Windows development system with Visual Studio 2008, Python
2.6.2+, and the msvc9compiler_stripruntimes_regexp2.diff patch applied,
verify that the embedded manifest in distutil generated PYD extension
files is stripped of the WinSxS VC.CRT dependency and that the
extensions can still be imported. The attached script (testpyd.py)
builds a minimal extension (testpyd.pyd), searches for the WinSxS VC.CRT
dependency within the pyd file, and imports the extension. The script
should run without exception.

Second, verify that distutil generated PYD extensions can also be
imported on a test system, which has no Visual Studio 2008 runtime
installed in %WINDIR%\WinSxS:
Install Windows XP SP3, preferably in a virtual machine. Do not install
any additional programs or patches, which might install the Visual
Studio 2008 runtime. Then install Python 2.6.2+ using the "Install just
for me" option. Try import the testpyd extension built on the
development system: run "python.exe -c 'import testpyd'" in a directory
containing the testpyd.pyd file (not the Python installation directory
containing python.exe). This should work without exception.

Importing the testpyd extension built without the patch fails on the
test system:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem.

Tested with Python 2.6.3 for Windows 32-bit.

----------
Added file: http://bugs.python.org/file15161/testpyd.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Sun Oct 18 21:34:28 2009
From: report at bugs.python.org (Lie Ryan)
Date: Sun, 18 Oct 2009 19:34:28 +0000
Subject: [issue7166] IDLE (python 3.1.1) syntax coloring for b'bytestring' and
	u'unicode' string literal
In-Reply-To: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
Message-ID: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>


New submission from Lie Ryan <lie.1296 at gmail.com>:

On python trunk and 3.2 IDLE, the b in b'' is not green colored.
On python 3.1 IDLE, the u in u'' is still colored, despite a SyntaxError.

(sorry, I don't have diff installed on my Windows machine)

Change on python trunk:
/Lib/idlelib/ColorDelegator.py
def make_pat():
    ....
    sqstring = r"(\b[rRuUbB])?'[^'\\\n]*(\\.[^'\\\n]*)*'?"
    dqstring = r'(\b[rRuUbB])?"[^"\\\n]*(\\.[^"\\\n]*)*"?'
    sq3string = r"(\b[rRuUbB])?'''[^'\\]*((\\.|'(?!''))[^'\\]*)*(''')?"
    dq3string = r'(\b[rRuUbB])?"""[^"\\]*((\\.|"(?!""))[^"\\]*)*(""")?'
    ....


And on py3k branch:
/Lib/idlelib/ColorDelegator.py
def make_pat():
    ....
    sqstring = r"(\b[rRbB])?'[^'\\\n]*(\\.[^'\\\n]*)*'?"
    dqstring = r'(\b[rRbB])?"[^"\\\n]*(\\.[^"\\\n]*)*"?'
    sq3string = r"(\b[rRbB])?'''[^'\\]*((\\.|'(?!''))[^'\\]*)*(''')?"
    dq3string = r'(\b[rRbB])?"""[^"\\]*((\\.|"(?!""))[^"\\]*)*(""")?'
    ....

----------
components: IDLE
messages: 94222
nosy: lieryan
severity: normal
status: open
title: IDLE (python 3.1.1) syntax coloring for b'bytestring' and u'unicode' string literal
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7166>
_______________________________________

From report at bugs.python.org  Sun Oct 18 21:34:46 2009
From: report at bugs.python.org (Lie Ryan)
Date: Sun, 18 Oct 2009 19:34:46 +0000
Subject: [issue7166] IDLE (python 3.1.1) syntax coloring for b'bytestring' and
	u'unicode' string literal
In-Reply-To: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
Message-ID: <1255894486.33.0.447476827042.issue7166@psf.upfronthosting.co.za>


Changes by Lie Ryan <lie.1296 at gmail.com>:


----------
versions: +Python 2.7, Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7166>
_______________________________________

From report at bugs.python.org  Sun Oct 18 22:03:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Oct 2009 20:03:12 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1255879125.44.0.193745924143.issue6952@psf.upfronthosting.co.za>
Message-ID: <4ADB747B.2090503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 1) I can comment the casts to maintain this goal.
> 2) Or change the output paramter const ness.
> 
> Given your feedback I'm guessing you want me to go further with 
> the use of const and do (2).

Ah, ok - as I said, I didn't look into detail further. IIUC, changing
output parameters to const could break existing code (right?); this
should be avoided absolutely.

Rather than having the casts, I think I would prefer to take no action
at these places; I recommend to discuss that on python-dev (some may
argue in favor of changing output pointers to const if that is
semantically correct).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sun Oct 18 22:04:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Oct 2009 20:04:22 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1255896262.48.0.0681147121056.issue3366@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Verified that r75454 makes the gamma test errors go away on a PPC Mac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sun Oct 18 22:47:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Oct 2009 20:47:41 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255898861.64.0.5417797814.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can build the docs by going to the Doc directory and typing "make
html" there. It isn't critical anyway.

The tests failed to run, I had to replace the KEYCERT declaration with:

    KEYCERT = os.path.join(os.path.dirname(__file__), "keycert.pem") 

(and add "import os" at the top)

Another remark: login() doesn't return the response, while it does on
the normal FTP class.

Apart from that, I'm trying to test on a TLS-enabled FTP server, but
even the regular FTP class doesn't seem to work with it (I get "500
Illegal PORT command" when calling retrlines('LIST')).

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Sun Oct 18 23:22:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Oct 2009 21:22:25 +0000
Subject: [issue7167] Smarter FTP passive mode
In-Reply-To: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
Message-ID: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I have come accross an FTP server which lftp (an Unix command-line
client) handles well but ftplib doesn't. Both ftplib and lftp are
configured to use passive mode (this server apparently doesn't handle
non-passive), but the address sent in response by the server is a
private IP. Here is a wireshark transcript of the FTP conversation done
by lftp:

220 172.29.AAA.BBB FTP server ready

FEAT

211-Features:
 LANG en
 MDTM
 UTF8
 AUTH TLS
 PBSZ
 PROT
 REST STREAM
 SIZE

211 End

LANG

200 Using default language en

OPTS UTF8 ON

200 UTF8 set to on

USER XXXX
331 Password required for ftth_rdvph

PASS XXXX
230 Connexion reussie pour ftth_rdvph

PWD

257 "/" is the current directory

PASV

227 Entering Passive Mode (172,29,AAA,BBB,195,84).

LIST

150 Opening ASCII mode data connection for file list

226 Transfer complete



As you see, lftp had no problem opening a data connection. It probably
notices that the address advertised in response to PASV doesn't respond
(after e.g. a 2s. timeout), and falls back on the host's known address
instead. In contrast, ftplib simply sits while the connection is
attempted and bails out at the end with a connection error.

----------
components: Library (Lib)
messages: 94226
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Smarter FTP passive mode
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7167>
_______________________________________

From report at bugs.python.org  Sun Oct 18 23:24:52 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Oct 2009 21:24:52 +0000
Subject: [issue7151] regrtest -j sometimes fails if output gets written to
	stderr by a test
In-Reply-To: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
Message-ID: <1255901092.1.0.00595978375923.issue7151@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: nobody -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7151>
_______________________________________

From report at bugs.python.org  Sun Oct 18 23:52:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Oct 2009 21:52:42 +0000
Subject: [issue7167] Smarter FTP passive mode
In-Reply-To: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
Message-ID: <1255902762.95.0.83626211775.issue7167@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

At least we could add an optional argument to set_pasv() so as to ignore
the host provided by the server. Here is a patch proposal.

----------
keywords: +patch
Added file: http://bugs.python.org/file15162/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7167>
_______________________________________

From report at bugs.python.org  Mon Oct 19 01:33:51 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Oct 2009 23:33:51 +0000
Subject: [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds
	fail with KeyError
In-Reply-To: <1254742115.57.0.346118025313.issue7064@psf.upfronthosting.co.za>
Message-ID: <1255908831.7.0.353553880314.issue7064@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Verified that the original regression reported against 2.6.3 when using 
setuptools 0.6c9 has been fixed and no longer exists in 2.6.4rc2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7064>
_______________________________________

From report at bugs.python.org  Mon Oct 19 01:56:44 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Oct 2009 23:56:44 +0000
Subject: [issue7149] 2.6.4rc1 regression: test_urllib2 fails on OS X with
	UnboundLocalError
In-Reply-To: <1255668597.22.0.497467299088.issue7149@psf.upfronthosting.co.za>
Message-ID: <1255910204.36.0.178179733655.issue7149@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Verified that test_urllib2 no longer fails with 2.6.4rc2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7149>
_______________________________________

From report at bugs.python.org  Mon Oct 19 03:00:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 01:00:00 +0000
Subject: [issue7168] Document PyFloat_AsString and PyFloat_AsReprString as
	deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

These functions are unsafe and I'd like to delete them. They've already
been deleted in py3k, per PEP 3100. They are no longer used internally
to the interpreter.

They should be documented as deprecated and as unsafe. They write to a
char* parameter, but don't take a length, so they could overwrite the
passed-in buffer.

There's some argument to be made that we should also document
PyFloat_AsStringEx, which is also deprecated and unsafe. But it is not
in a .h file in 2.4, 2.5, or 2.6, so I'd like to just delete it for 2.7.

----------
assignee: georg.brandl
components: Documentation
messages: 94230
nosy: eric.smith, georg.brandl
priority: normal
severity: normal
status: open
title: Document PyFloat_AsString and PyFloat_AsReprString as deprecated and unsafe
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________

From report at bugs.python.org  Mon Oct 19 04:51:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Oct 2009 02:51:27 +0000
Subject: [issue7166] IDLE (python 3.1.1) syntax coloring for b'bytestring' and
	u'unicode' string literal
In-Reply-To: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
Message-ID: <1255920687.68.0.57733771598.issue7166@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7166>
_______________________________________

From report at bugs.python.org  Mon Oct 19 04:55:03 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Oct 2009 02:55:03 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1255920903.05.0.457241186214.issue1160@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type: crash -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
_______________________________________

From report at bugs.python.org  Mon Oct 19 04:56:48 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Oct 2009 02:56:48 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1255921008.4.0.820729742904.issue1673007@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 19 10:50:02 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Oct 2009 08:50:02 +0000
Subject: [issue7167] Smarter FTP passive mode
In-Reply-To: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
Message-ID: <1255942202.59.0.536965316117.issue7167@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

If the server is behind a NAT it should be up to the administrator to
properly configure it so that the internal address gets replaced in
PASV/EPSV replies.
Any FTP server provides this possibility.
IMHO, this is not in the realm of problems which should be dealt by
ftplib. It's just server's fault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7167>
_______________________________________

From report at bugs.python.org  Mon Oct 19 13:30:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 11:30:07 +0000
Subject: [issue7167] Smarter FTP passive mode
In-Reply-To: <1255942202.59.0.536965316117.issue7167@psf.upfronthosting.co.za>
Message-ID: <1255952037.5555.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If the server is behind a NAT it should be up to the administrator to
> properly configure it so that the internal address gets replaced in
> PASV/EPSV replies.
> Any FTP server provides this possibility.
> IMHO, this is not in the realm of problems which should be dealt by
> ftplib. It's just server's fault.

Yes, probably. The point was only that lftp seemed to be able to handle
it, so I thought that maybe ftplib could be enhanced to match that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7167>
_______________________________________

From report at bugs.python.org  Mon Oct 19 14:40:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 12:40:36 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1255956036.12.0.65221506976.issue1160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Kristall, can you post the troublesome regular expression?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
_______________________________________

From report at bugs.python.org  Mon Oct 19 14:55:20 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Oct 2009 12:55:20 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255956920.42.0.212039084217.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> You can build the docs by going to the Doc directory and typing "make
> html" there. It isn't critical anyway.

Done. It's well formatted now.

> The tests failed to run, I had to replace the KEYCERT declaration with:
>    KEYCERT = os.path.join(os.path.dirname(__file__), "keycert.pem") 
> (and add "import os" at the top)

Done.


> Another remark: login() doesn't return the response, while it does on
> the normal FTP class.

Good catch, thanks. 
Done.

> Apart from that, I'm trying to test on a TLS-enabled FTP server, but
> even the regular FTP class doesn't seem to work with it (I get "500
> Illegal PORT command" when calling retrlines('LIST')).

Strange. I doubt this issue is related with my changes.
I tried FTP_TLS agains proftpd, filezilla server and pyftpdlib and it
works fine.

New patch in attachment btw.

----------
Added file: http://bugs.python.org/file15163/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 14:56:43 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 12:56:43 +0000
Subject: [issue7168] Document PyFloat_AsString and PyFloat_AsReprString as
	deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255957003.31.0.258645132856.issue7168@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee: georg.brandl -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________

From report at bugs.python.org  Mon Oct 19 15:02:36 2009
From: report at bugs.python.org (jmb)
Date: Mon, 19 Oct 2009 13:02:36 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1255957356.24.0.227759619349.issue2889@psf.upfronthosting.co.za>


Changes by jmb <jeberger at free.fr>:


----------
nosy: +jmb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Mon Oct 19 15:26:45 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 13:26:45 +0000
Subject: [issue7168] Document PyFloat_AsString and PyFloat_AsReprString as
	deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255958805.51.0.689359354798.issue7168@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Proposed patch attached.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file15164/issue7168.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________

From report at bugs.python.org  Mon Oct 19 15:33:48 2009
From: report at bugs.python.org (skelker)
Date: Mon, 19 Oct 2009 13:33:48 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>


New submission from skelker <steve.kelker at dtn.com>:

I noticed today if I attempt to create a ZipFile object for read access,
and the zip file is zero bytes, the ZipFile object throws an exception,
but there is still an open handle to the file.  So if I catch that
exception, and then try to delete the file, the delete then fails.  I
have attached a script that replicates the issue.

----------
components: Windows
files: zipfileCrash.py
messages: 94236
nosy: skelker
severity: normal
status: open
title: zipfile leaves a file handle open if file is zero size
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15165/zipfileCrash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Mon Oct 19 16:09:48 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 14:09:48 +0000
Subject: [issue7168] Document PyFloat_AsString and PyFloat_AsReprString as
	deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255961388.88.0.147374543332.issue7168@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Updated patch based on Georg's input.

----------
Added file: http://bugs.python.org/file15166/issue7168.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________

From report at bugs.python.org  Mon Oct 19 16:15:33 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 14:15:33 +0000
Subject: [issue7168] Document PyFloat_AsString and PyFloat_AsReprString as
	deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255961733.67.0.64815228781.issue7168@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file15164/issue7168.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________

From report at bugs.python.org  Mon Oct 19 16:41:04 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 19 Oct 2009 14:41:04 +0000
Subject: [issue7168] Document PyFloat_AsString and PyFloat_AsReprString as
	deprecated and unsafe
In-Reply-To: <1255914000.67.0.0340372687957.issue7168@psf.upfronthosting.co.za>
Message-ID: <1255963264.49.0.196502869124.issue7168@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

A slightly improved version checked in as r75510.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7168>
_______________________________________

From report at bugs.python.org  Mon Oct 19 16:50:24 2009
From: report at bugs.python.org (Michael J. Fromberger)
Date: Mon, 19 Oct 2009 14:50:24 +0000
Subject: [issue7160] Crash when returning a 64-bit char pointer in Python
	2.6.3 ctypes
In-Reply-To: <1255797064.79.0.0899403156454.issue7160@psf.upfronthosting.co.za>
Message-ID: <1255963824.27.0.327494202813.issue7160@psf.upfronthosting.co.za>


Michael J. Fromberger <michael.j.fromberger at gmail.com> added the comment:

Thank you for setting me straight. 

I see now that I misunderstood the scope of `CFUNCTYPE`, as I was using 
it as a general wrapper when in fact it's only needed for callbacks. 
Mistakenly, I inferred from reading section 16.15.2.4 of the ctypes 
manual [1] that it would be necessary to create prototype wrappers for 
calls into the foreign library as well. Obviously that is not the case, 
since your described solution works fine.

[1] <http://www.python.org/doc/2.6.3/library/ctypes.html#function-
prototypes>

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7160>
_______________________________________

From report at bugs.python.org  Mon Oct 19 17:09:56 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Oct 2009 15:09:56 +0000
Subject: [issue5713] smtplib gets out of sync if server returns a 421 status
In-Reply-To: <1239049825.43.0.457403750239.issue5713@psf.upfronthosting.co.za>
Message-ID: <1255964996.1.0.405206375887.issue5713@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5713>
_______________________________________

From report at bugs.python.org  Mon Oct 19 17:16:26 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Oct 2009 15:16:26 +0000
Subject: [issue5713] smtplib gets out of sync if server returns a 421 status
In-Reply-To: <1239049825.43.0.457403750239.issue5713@psf.upfronthosting.co.za>
Message-ID: <1255965386.17.0.334717156902.issue5713@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

So, if I understand the issue and the RFC correctly, when receiving a
421, we should close the connection and, if the 421 was received in the
"rcpt" phase, give back a dictionary with all pending directions as
"421" code, so the sending code knows they are 4xx codes and should
retry again later.

What return code would be give back if we get 421 in other situations?.
Maybe a regular "connection close"?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5713>
_______________________________________

From report at bugs.python.org  Mon Oct 19 17:33:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 15:33:25 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255966405.73.0.912601411199.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is ok to me. Perhaps Bill wants to take a look, otherwise I
think you can commit.

----------
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 17:33:49 2009
From: report at bugs.python.org (egreen)
Date: Mon, 19 Oct 2009 15:33:49 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255966429.35.0.473877013532.issue7080@psf.upfronthosting.co.za>


egreen <egreen at operamail.com> added the comment:

The tests in TestEnUSCollation I added don't work for all encodings
(e.g. Asian ones, or ASCII).  Now checked for encodings which are known
to work.

Found and fixed a bug (result not returned) in getpreferredencoding in
Lib/locale.py.

This test is skipped on Mac, since r30377.  I've tested it on 10.3
(PPC), and it passed, so I enabled it again.

I did, however, find that FreeBSD and Mac OS X have known bugs in
wcscoll and wcsxfrm: http://www.freebsd.org/cgi/man.cgi?query=wcsxfrm
(cf. patch)

----------
Added file: http://bugs.python.org/file15167/strxfrm_fixes_and_collation_tests_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Mon Oct 19 18:40:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Oct 2009 16:40:54 +0000
Subject: [issue7151] regrtest -j sometimes fails if output gets written to
	stderr by a test
In-Reply-To: <1255719076.69.0.751832436592.issue7151@psf.upfronthosting.co.za>
Message-ID: <1255970454.97.0.396084382742.issue7151@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to trunk in r75503, and py3k in r75513.

----------
assignee:  -> r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7151>
_______________________________________

From report at bugs.python.org  Mon Oct 19 19:00:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 17:00:00 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1255966405.73.0.912601411199.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255971830.5555.60.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

A last problem:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attribute name must be string, not 'classobj'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 19:06:31 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 19 Oct 2009 17:06:31 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1255971991.19.0.287007801969.issue6941@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser <kbk at shore.net>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Mon Oct 19 19:07:25 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 19 Oct 2009 17:07:25 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1255972045.36.0.624085030233.issue6717@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser <kbk at shore.net>:


----------
nosy: +kbk
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon Oct 19 19:12:19 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 19 Oct 2009 17:12:19 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255972339.46.0.0748987342491.issue7133@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Is there some reason that this is not being checked
in?  The build has been broken for five days.  IMO,
either revert the offending code or check this in.

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________

From report at bugs.python.org  Mon Oct 19 19:36:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 17:36:17 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255973777.01.0.427348805549.issue7133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I was hoping for Bill (the _ssl maintainer)'s opinion on this, but
you're right, it should be checked in.

----------
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________

From report at bugs.python.org  Mon Oct 19 20:00:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 18:00:18 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1255975218.71.0.200285001394.issue7133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r75529.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7133>
_______________________________________

From report at bugs.python.org  Mon Oct 19 20:25:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 18:25:41 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1255976741.93.0.450414195881.issue5833@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the readline 6.0 fix to trunk, py3k and 3.1. I'll commit
it to 2.6 when the branch is unfrozen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Mon Oct 19 20:38:44 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Oct 2009 18:38:44 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255977524.94.0.559041831381.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> A last problem:
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: attribute name must be string, not 'classobj'

Mmmm this doesn't say much.
When does it happen?
Is that the complete traceback message?

> The patch is ok to me. Perhaps Bill wants to take a look.

I'd like the opinion of Bill too, specifically about what he was talking  
about in comments 62699 and 64093.

> otherwise I think you can commit.

I don't have commit privileges. Someone else should do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 20:44:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 18:44:54 +0000
Subject: [issue7145] UTF-16 BOM is not written by socket.makefile (but is
	expected by read)
In-Reply-To: <1255640141.97.0.741235595608.issue7145@psf.upfronthosting.co.za>
Message-ID: <1255977894.76.0.318331350299.issue7145@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The explanation is that sockets are not seekable, but the heuristic to
decide whether to write a BOM relies on tell() to return 0 on start-of-file.
If we unconditionally wrote a BOM, there would be a risk of duplicate
BOMs depending on the use case, which is more annoying than lacking a
BOM at the beginning.

----------
components: +IO
nosy: +pitrou
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________

From report at bugs.python.org  Mon Oct 19 20:47:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 18:47:05 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255978025.31.0.553499258152.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, sorry, roundup's e-mail interface ate part of the message.
The error happens when doing "from ftplib import *". Apparently __all__
contains a non-string value.

> I don't have commit privileges. Someone else should do it.

Ok, I'll do it if Bill doesn't give a sign of life.

----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 20:54:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 18:54:26 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255978466.81.0.565555554498.issue2054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Regarding msg64093, the only API change Bill's suggestion would entail
is an additional optional parameter to the constructor, so adding it
later would be backwards-compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:02:31 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Oct 2009 19:02:31 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1255978951.34.0.343923165673.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> Ah, sorry, roundup's e-mail interface ate part of the message.
> The error happens when doing "from ftplib import *". Apparently 
__all__
> contains a non-string value.

Oh, shame on me! You're right.
Thanks for the great review you're doing.

> Regarding msg64093, the only API change Bill's suggestion would entail
> is an additional optional parameter to the constructor, so adding it
> later would be backwards-compatible.

Good.
Possibly there might be another change we might want to do in future, 
which is adding support for CCC command, useful for reverting the 
control connection back to clear-text.
I remember I tried to do that at the time I submitted the first patch 
but there was a problem with ssl's unwrap() method (I really don't 
remember what exactly).

Anyway, I'll try to put hands on that soon and let you know what 
happens.
The change should be backward compatible as it just consists in adding a 
ccc() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:23:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 19:23:23 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255980203.54.0.237904120812.issue7080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice work, thanks!
One detail: when giving you credit, who should I mention? just "egreen"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:35:19 2009
From: report at bugs.python.org (Derk Drukker)
Date: Mon, 19 Oct 2009 19:35:19 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255980919.42.0.682318686351.issue7080@psf.upfronthosting.co.za>


Derk Drukker <egreen at operamail.com> added the comment:

I've entered my real name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:35:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 19:35:55 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255980955.12.0.447775956849.issue7080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:39:24 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Oct 2009 19:39:24 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1255981164.48.0.886248205349.issue7057@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Tkinter
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:43:03 2009
From: report at bugs.python.org (Preston Landers)
Date: Mon, 19 Oct 2009 19:43:03 +0000
Subject: [issue1378] fromfd() and dup() for _socket on WIndows
In-Reply-To: <1194103455.44.0.390687208828.issue1378@psf.upfronthosting.co.za>
Message-ID: <1255981383.88.0.165573250421.issue1378@psf.upfronthosting.co.za>


Preston Landers <planders at gmail.com> added the comment:

Hmm... revision 59004 appears to be unrelated to the main issue at hand.
  As far as I can tell now the status is this: the dup() and fromfd()
support appears to be present in Python 3000 for Windows - at least the
py3k branch. I didn't check the releases.  But it's not present in 2.6
or trunk.  I guess as far as I'm concerned that's fine. I'm going to use
a patch to 2.6.3 to implement it for my purposes anyway.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1378>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:48:35 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 19 Oct 2009 19:48:35 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1255981715.32.0.0126730958683.issue6672@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:50:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Oct 2009 19:50:01 +0000
Subject: [issue7080] locale.strxfrm raises MemoryError
In-Reply-To: <1254956503.26.0.613752326447.issue7080@psf.upfronthosting.co.za>
Message-ID: <1255981801.1.0.245894655615.issue7080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is now committed to py3k (r75539) and 3.1 (r75541), closing.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7080>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:50:06 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 19 Oct 2009 19:50:06 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1255981806.36.0.110872286822.issue6672@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

svn.python.org seems to be up again.  Could you create a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:48:09 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 19 Oct 2009 21:48:09 +0000
Subject: [issue7170] subclasses of (some) built-in types are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The documentation for weakref contains the following example:

http://docs.python.org/3.1/library/weakref.html

----------------------------------------------
Several built-in types such as list and dict do not directly support
weak references but can add support through subclassing:

class Dict(dict):
    pass

obj = Dict(red=1, green=2, blue=3)   # this object is weak referenceable
----------------------------------------------

While this works fine for list and dict, it does not work for tuple or int:

>>> class Tuple(tuple):
...     pass
...
>>> obj = Tuple()
>>> weakref.ref(obj)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'Tuple' object

I've tried it in Python 2.5, 2.6, and 3.1.

----------
components: Interpreter Core
messages: 94260
nosy: stutzbach
severity: normal
status: open
title: subclasses of (some) built-in types are not weakref-able
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7170>
_______________________________________

From report at bugs.python.org  Tue Oct 20 01:20:26 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 19 Oct 2009 23:20:26 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

According to the documentation, Microsoft now supports inet_ntop and
inet_pton
(http://msdn.microsoft.com/en-us/library/cc805843%28VS.85%29.aspx). This
capability should be integrated into the socket module so it is
supported cross-platform.

----------
components: IO
messages: 94261
nosy: jaraco
severity: normal
status: open
title: Add inet_ntop and inet_pton support for Windows
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Tue Oct 20 01:40:17 2009
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 19 Oct 2009 23:40:17 +0000
Subject: [issue7172] BaseHTTPServer.BaseHTTPRequestHandler.responses[405] has
	a small mistake
In-Reply-To: <1255995617.49.0.338501065571.issue7172@psf.upfronthosting.co.za>
Message-ID: <1255995617.49.0.338501065571.issue7172@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

BaseHTTPServer.BaseHTTPRequestHandler.responses contains a mapping from 
HTTP status codes to the 2-ple (shortmessage, longmessage), based on RFC 
2616.

The 2-ple for 405 is ('Method Not Allowed','Specified method is invalid 
for this server.'),

RFC 405 says "An origin server SHOULD return the status code 405 (Method 
Not Allowed) if the method is known by the origin server but not allowed 
for the requested resource.

I think the message should be "Specified method is invalid for this 
resource". That is, change "server" to "resource".

----------
components: Library (Lib)
messages: 94262
nosy: dalke
severity: normal
status: open
title: BaseHTTPServer.BaseHTTPRequestHandler.responses[405] has a small mistake
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7172>
_______________________________________

From report at bugs.python.org  Tue Oct 20 02:10:49 2009
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 20 Oct 2009 00:10:49 +0000
Subject: [issue7172] BaseHTTPServer.BaseHTTPRequestHandler.responses[405] has
	a small mistake
In-Reply-To: <1255995617.49.0.338501065571.issue7172@psf.upfronthosting.co.za>
Message-ID: <1255997449.25.0.727194582077.issue7172@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

Wasn't thinking. I'm not quoting from "RFC 405", I'm quoting the 405 
section from RFC 2616.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7172>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:44:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2009 02:44:47 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1256006687.9.0.508322620569.issue7119@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem here is that when you are constructing a message the
boundary is calculated "as needed", and returning the list of items is
not one of the times when the boundary is needed.  I agree that it is
not good design that as_string can mutate the object it is called on;
however the alternative (throwing away the calculated boundary after
message Generation) means that stringifying the same message twice would
produce two strings that are not equal...which also seems like bad
design.  But perhaps that would be less bad design.

The underlying problem here is that the things being returned by items
are strings, when they should be Header objects.  That problem isn't
going to be resolved until the email package rewrite happens.

----------
nosy: +barry, r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________

From report at bugs.python.org  Tue Oct 20 05:00:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Oct 2009 03:00:09 +0000
Subject: [issue7170] subclasses of (some) built-in types are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1256007609.26.0.138872413842.issue7170@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

That's why it says "several" builtin types.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7170>
_______________________________________

From report at bugs.python.org  Tue Oct 20 05:14:58 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 20 Oct 2009 03:14:58 +0000
Subject: [issue7170] subclasses of (some) built-in types are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1256008498.58.0.68620239394.issue7170@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I parsed the documentation this way:

"Several built-in types such as list and dict do not directly support
weak references" (true)

"but [all of those that do not directly support weak references] can add
support through subclassing"

I would expect there to be exactly two groups of items:
- types that support weak references directly
- types where it can be added through subclassing

Is there some technical reason why int, tuple, and others cannot support
it through subclassing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7170>
_______________________________________

From report at bugs.python.org  Tue Oct 20 05:22:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Oct 2009 03:22:55 +0000
Subject: [issue7170] subclasses of (some) built-in types are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1256008975.67.0.82931927111.issue7170@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The documentation should be rewritten for clarity then. The reason you
can't take weakrefs of those types is because they are implemented as
"varsized" objects, so there is no constant place to add a weakref list
in the memory layout of the objects.

----------
assignee:  -> georg.brandl
components: +Documentation -Interpreter Core
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7170>
_______________________________________

From report at bugs.python.org  Tue Oct 20 11:21:17 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 20 Oct 2009 09:21:17 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Running the Cython compiler under Python 3.1.1 and 3.2 (SVN) corrupts
PyThreadState->exc_value by leaving a dead reference. Printing the value
then leads to a crash.

This bug is about plain Python code, no Cython built extension modules
involved.

Steps to reproduce the problem:

- get Cython from http://hg.cython.org/cython-devel (see the bz2/zip/gz
links on the left to get an archive without doing a checkout)

- apply the attached patch, which simply prints sys.exc_info() during
the compiler run at a place where it's known to be corrupted

- execute the following to run a single test in the test suite:

   python3.1 runtests.py --no-cpp --no-pyregr --no-doctest -vv \
                                  'compile\.first_assignment'

- expect a crash after printing "HERE1"

Before exc_info gets corrupted, we make heavy use of generators to
traverse the parse tree (see Cython/Compiler/TreePath.py), while being
inside of a recursive traversal of the tree already (see the
"VisitorTransform" class and its base class in
Cython/Compiler/Visitor.py). The code section that links the two is in
the class "TreeAssertVisitor" at the end of Cython/TestUtils.py, where
the patch applies. As exc_info doesn't get corrupted during the normal
recursive tree transformation traversals before that, the generator
usage in TreePath.py is likely related to the crash.

The crash was found and reproduced under two different Linux x86 systems.

----------
components: Interpreter Core
files: crash-patch.patch
keywords: patch
messages: 94268
nosy: scoder
severity: normal
status: open
title: Cython compiler run crashes CPython 3.1.1 and 3.2
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15168/crash-patch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Tue Oct 20 11:24:24 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 20 Oct 2009 09:24:24 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1256030664.1.0.424290484932.issue7173@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I should add that the crash doesn't necessarily happen during the first
test run, which also converts the Cython source to Py3 using 2to3.
However, once that's done, running the test a second time crashes reliably.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Tue Oct 20 12:21:51 2009
From: report at bugs.python.org (Andrew Shuiu)
Date: Tue, 20 Oct 2009 10:21:51 +0000
Subject: [issue7174] modeule: queue class: PriorityQueue
In-Reply-To: <1256034111.78.0.486242664983.issue7174@psf.upfronthosting.co.za>
Message-ID: <1256034111.78.0.486242664983.issue7174@psf.upfronthosting.co.za>


New submission from Andrew Shuiu <asuiu at bitdefender.com>:

Puting 2 tuples like (100, data1), (100, data2) in a PriorityQueue
generates an builtins.TypeError: unorderable types: data1 < data2

Code which generates error:
theQueue.put((100, object1()),True)
theQueue.put((100, object1()),True)

Snippet from error:
builtins.TypeError: unorderable types: Crawler() < Crawler()
File "d:\work\python\gglcrwl.py", line 89, in <module>
  crawlGroup.Process()
File "d:\work\python\GglCrwLib.py", line 1056, in Process
  globs.linksQueue.put((globs.cDefLinkPriority,
Crawler(u.title_url,ca)),True)
File "C:\Program Files\Python31\Lib\queue.py", line 153, in put
  self._put(item)
File "C:\Program Files\Python31\Lib\queue.py", line 242, in _put
  heappush(self.queue, item)

----------
components: Library (Lib)
messages: 94270
nosy: asuiu
severity: normal
status: open
title: modeule: queue class: PriorityQueue
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7174>
_______________________________________

From report at bugs.python.org  Tue Oct 20 12:54:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2009 10:54:09 +0000
Subject: [issue7174] modeule: queue class: PriorityQueue
In-Reply-To: <1256034111.78.0.486242664983.issue7174@psf.upfronthosting.co.za>
Message-ID: <1256036049.37.0.880767947104.issue7174@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In python3 (unlike 2) objects are by default unorderable.  You'll need
to define an ordering for your objects in order to use them in a
PriorityQueue, whether or not they are inside a tuple.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7174>
_______________________________________

From report at bugs.python.org  Tue Oct 20 13:21:17 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Oct 2009 11:21:17 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

[.]pydistutils.cfg will be deprecated in favor of a single
"distutils.cfg", located in .local/ alongside the files added for
example by the per user-site packages.

----------
assignee: tarek
components: Distutils
messages: 94272
nosy: tarek
priority: normal
severity: normal
status: open
title: unify pydistutils.cfg and distutils.cfg and use .local
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 14:00:27 2009
From: report at bugs.python.org (=?utf-8?q?Jan_Schl=C3=BCter?=)
Date: Tue, 20 Oct 2009 12:00:27 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1256040027.22.0.700635713903.issue6672@psf.upfronthosting.co.za>


Jan Schl?ter <python-bugs at jan-schlueter.de> added the comment:

Hello!

Thanks, you're right. I have created a patch against the latest SVN 
revision (75557) of branches/release26-maint/Include/pyport.h. The 
patch also applies fine to trunk/Include/pyport.h.
As it applies to both versions, I have created the patch directly from 
inside the Include directory rather than from the svn root.

As I am abroad for a couple of months and do not have access to my 
Windows machine, I currently cannot test the patch (i.e. compile Python 
on Windows using Mingw), but I successfully compiled the PyMedia 
package using Mingw and the modified pyport.h.

Please let me know if you have any questions or remarks!

----------
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file15169/pyport-issue6672.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Tue Oct 20 15:41:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Oct 2009 13:41:12 +0000
Subject: [issue7099] Decimal.is_normal should return True even for numbers
	with exponent > Emax
In-Reply-To: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>
Message-ID: <1256046072.67.0.0260085579417.issue7099@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r75561 (trunk), r75662 (py3k) and r75663 (release31-maint).
release26-maint is still frozen; leaving open for the backport.

----------
resolution:  -> fixed
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7099>
_______________________________________

From report at bugs.python.org  Tue Oct 20 15:48:57 2009
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Augustsson?=)
Date: Tue, 20 Oct 2009 13:48:57 +0000
Subject: [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
Message-ID: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>


New submission from Bj?rn Augustsson <oggust at gmail.com>:

Summary: "sum()" doesn't work on lists, even though the docs says it 
should.

The docs say:

"Note that sum(range(n), m) is equivalent to reduce(operator.add, 
range(n), m)"

That's not true.
--------------------------------
import operator

a=[1,2]
b=["x","y"]

reduce(operator.add, [a,b])
# Works, gives "[1, 2, 'x', 'y']" as expected.

sum ([a,b])
# Does not work, gives: "TypeError: unsupported operand type(s) for +: 
'int' and 'list'"
--------------------------------
(And "a + b" obviously works too.)

/August.

----------
components: None
messages: 94275
nosy: oggust
severity: normal
status: open
title: sum() doesn't work for lists.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________

From report at bugs.python.org  Tue Oct 20 15:53:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Oct 2009 13:53:23 +0000
Subject: [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
Message-ID: <1256046803.04.0.349199148652.issue7176@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To sum lists, you need to supply a second argument to sum:

>>> sum([[1, 2], ['x', 'y']], [])
[1, 2, 'x', 'y']

The default value of the second argument is 0, which is why you're seeing 
the TypeError.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________

From report at bugs.python.org  Tue Oct 20 15:59:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Oct 2009 13:59:16 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1256047156.97.0.704680265605.issue7048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I just want to note another problem with logb:  it doesn't use the correct 
context when processing NaNs.  This needs a test and a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:07:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Oct 2009 14:07:42 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1256047662.35.0.400748364244.issue7048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry;  ignore that last.  I was confused by the fact that the _check_nans 
call came before the 'if context is None' test.  But _check_nans deals 
correctly with a context of None, so logb is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:39:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 14:39:52 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256049592.7.0.244144299996.issue7175@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why is this? .local/ contains machine-installed files while
.pydistutils.cfg is edited by the user.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:47:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 14:47:01 +0000
Subject: [issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows
	and 'x86-64' on Linux
In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
Message-ID: <1256050021.5.0.270337257345.issue7146@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

x86-64 is now the common name for the 64-bit instruction set implemented
by mainstream AMD and Intel processors. Even on the AMD web site,
"x86-64" shows up more often than "AMD64" (says Google).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7146>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:53:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 14:53:37 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1256050417.41.0.672993250636.issue6845@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:55:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Oct 2009 14:55:37 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256050537.05.0.745907503857.issue7175@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's what is returned by site.getuserbase()

(which uses PYTHONUSERBASE, and defaults to ~/.local)

PYTHONUSERBASE is the root of Python user-specific paths so it makes
sense to have all Python related files in there.

This came up with the discussion we had with others at Distutils-SIG

read this thread here for more info:
http://mail.python.org/pipermail/distutils-sig/2009-August/012865.html

[.]pypirc should probably go there too.

----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:03:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 15:03:38 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256050537.05.0.745907503857.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256051248.5492.19.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's what is returned by site.getuserbase()
> 
> (which uses PYTHONUSERBASE, and defaults to ~/.local)

Well, that makes it the user-specific equivalent of /usr or /usr/local.
Do you put your configuration files in /usr/local ? Why put them
in .local ?

> PYTHONUSERBASE is the root of Python user-specific paths so it makes
> sense to have all Python related files in there.

That doesn't make sense actually, since .local isn't Python-specific. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:08:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 15:08:18 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1256051298.21.0.530607342025.issue1722344@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks good to me.
And since Py_Finalize() claims to "destroy all sub-interpreters" and
"free all memory allocated by the Python interpreter", I guess your
approach makes sense. Can you commit?

----------
resolution:  -> accepted
stage: patch review -> commit review
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:11:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 15:11:31 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256051491.16.0.498209313213.issue7175@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've read the thread now and I think the original proposal of having a
~/.python was more sensible and more user-friendly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:17:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2009 15:17:12 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256051832.37.0.0982830216092.issue7175@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

+1 to what Antoine said.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:20:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 15:20:16 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1256052016.26.0.729469543597.issue6845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

According to the RFC, the argument to REST can be any string of
printable characters. However, does it happen for clients to put
non-digits in there?
(that is, are there any implementations where the argument to REST is
something else than the byte offset from the start of file?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:21:13 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Oct 2009 15:21:13 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256052073.52.0.879434475265.issue7175@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> Well, that makes it the user-specific equivalent of /usr or /usr/local.
> Do you put your configuration files in /usr/local ? 
> Why put them in .local ?

The distutils.cfg file is located in the distutils package itself !

So the target is ~/.local/pythonX.X/site-packages/distutils/distutils.cfg

(sorry if that was unclear)

Now, I would totally agree to have a better ~/.NAME to reunite
user-specific *configuration* file for Python, but that would be yet
another directory for user-specific Python files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:37:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 15:37:35 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256052073.52.0.879434475265.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256052403.5492.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The distutils.cfg file is located in the distutils package itself !
> 
> So the target is ~/.local/pythonX.X/site-packages/distutils/distutils.cfg

Ah, that's horrible. -1 to that.
Configuration files should be easily findable by skimming through the
dot-files in the user's directory. ~/.python fulfills that condition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:50:29 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Oct 2009 15:50:29 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256053829.53.0.130169587799.issue7175@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I like ~/.python very much too (that was my initial proposal IIRC). 

I guess the best way to add this support is to provide a new api in
site.py, that returns this folder.

Distutils can move pypirc and distutils.cfg file there.

Now for the global distutils.cfg, if we want to have it somewhere else
that the distutils package directory itself, we would need a
"/etc/python" scheme for instance, that could be also added in site.py.

I don't know though how the latter would look under windows

----------
nosy: +barry, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:11:41 2009
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 20 Oct 2009 16:11:41 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1256055101.37.0.384545180821.issue1722344@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Nope, no access.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:48:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 16:48:04 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1256057284.61.0.0889872775328.issue1722344@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I'll do it then!

----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:50:41 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Tue, 20 Oct 2009 16:50:41 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1256057441.06.0.681834344356.issue6845@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

I think that a non-digit REST argument is an error. But I've tested some
ftp servers and they don't return an error code, they just set REST to 0
and return some OK code. Finally, ftplib doesn't check that, so if
someone accidentally passes a non-digit argument it could be a difficult
bug to spot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Oct 20 19:32:08 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 20 Oct 2009 17:32:08 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256053829.53.0.130169587799.issue7175@psf.upfronthosting.co.za>
Message-ID: <4ADDF415.7070702@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> 
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
> I like ~/.python very much too (that was my initial proposal IIRC). 

+1 on that name as well.

One thing to note though: it is well possible that a user uses
multiple Python versions. With just one such directory, all
versions would look in the same directory for the configuration
files and this could lead to incompatibilities, e.g. Python 2.7
might not like that Python 3.6 needs in some config file (for
whatever reason).

> Now for the global distutils.cfg, if we want to have it somewhere else
> that the distutils package directory itself, we would need a
> "/etc/python" scheme for instance, that could be also added in site.py.
>
> I don't know though how the latter would look under windows

I think Subversion get's this pretty right, so we might want
to follow their scheme:

http://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Tue Oct 20 19:59:01 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 20 Oct 2009 17:59:01 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1256061541.57.0.799054582122.issue6845@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

The patch looks good to me.
Only two little remarks:

1: I'd create two new separate tests rather than appending them to
existent ones.

2: > self.client.retrbinary('retr', received.append, rest=str(rest))

str() should be useless here.

> According to the RFC, the argument to REST can be any string of
> printable characters. However, does it happen for clients to put
> non-digits in there?

It shouldn't happen but in any case I woulnd't want ftplib to check for
such a kind of thing.
Deciding whether the REST argument is invalid is up to the server, in
which case it will send a 4xx/5xx error response.

> But I've tested some ftp servers and they don't return an
> error code, they just set REST to 0 and return some OK code.

IMHO a bad design choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Oct 20 20:48:19 2009
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Augustsson?=)
Date: Tue, 20 Oct 2009 18:48:19 +0000
Subject: [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
Message-ID: <1256064499.79.0.679600833697.issue7176@psf.upfronthosting.co.za>


Bj?rn Augustsson <oggust at gmail.com> added the comment:

Er, that's fairly weird...

Couldn't it do eg "type(first argument)", and if it's a list, 
replace the 0 with []?

What's the second argument's use anyway?
  s = sum([1,2,3,4]) + 3
seems a lot clearer than
  s = sum([1,2,3,4], 3)
and those seem to be equivalent.

Thanks,
/August.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:19:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Oct 2009 19:19:21 +0000
Subject: [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
Message-ID: <1256066361.67.0.856908036986.issue7176@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

One use of the start argument is used to specify an initial zero/metpy
value for the summation:  0  or  0.0   or Decimal(0)  or  [].

BTW, sum() isn't a good technique for concatenating lists.  Instead use
something like:

   result = []
   for seq in data:
      result.extend(seq)

A fast one-liner version:
   result = list(itertools.chain.from_iterable(seq))

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:20:05 2009
From: report at bugs.python.org (Christopher Jefferson)
Date: Tue, 20 Oct 2009 20:20:05 +0000
Subject: [issue7177] Unclear warning for subprocess.call
In-Reply-To: <1256070005.74.0.0266256477403.issue7177@psf.upfronthosting.co.za>
Message-ID: <1256070005.74.0.0266256477403.issue7177@psf.upfronthosting.co.za>


New submission from Christopher Jefferson <chris at bubblescope.net>:

I wandered across subprocess.call as it was mentioned as a replacement for os.system. The 
following large warning is attached to it:

Warning Like Popen.wait(), this will deadlock if the child process generates enough output to a 
stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to accept more data.

This scared my off completely, and I assumed the function was simply broken, as I assumed 
"stdout pipe" just meant that wherever stdout was sent by default.

I now believe this warning only applies if 'stdout=PIPE', or similar, is used explicitally.

Could this warning be better worded, perhaps adding "if stdout or stderr are explicitly 
redirected", as in:

Warning Like Popen.wait(), if stdout or stderr are explicitly redirected this will deadlock if 
the child process generates enough output to a stdout or stderr pipe such that it blocks 
waiting for the OS pipe buffer to accept more data.

----------
assignee: georg.brandl
components: Documentation
messages: 94297
nosy: azumanga, georg.brandl
severity: normal
status: open
title: Unclear warning for subprocess.call
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7177>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:42:29 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 20 Oct 2009 20:42:29 +0000
Subject: [issue7170] subclasses of (some) built-in types are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1256071349.57.0.641128620264.issue7170@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

That's fair.  I suggest the following change:

current text:
"Several built-in types such as list and dict do not directly support
weak references but can add support through subclassing:"

new text:
"Several built-in types such as list and dict do not directly support
weak references but can add support through subclassing, as shown below.
 Other built-in types such as tuple and int do not support weak
references even when subclassed."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7170>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:59:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Oct 2009 20:59:33 +0000
Subject: [issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows
	and 'x86-64' on Linux
In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za>
Message-ID: <1256072373.66.0.997819294051.issue7146@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm not sure that changing this would do any good. Applications may rely
on the status quo, so I fail to see the point in breaking them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7146>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:13:09 2009
From: report at bugs.python.org (kuhnsjohn)
Date: Tue, 20 Oct 2009 21:13:09 +0000
Subject: [issue7178] open function's buffering parameter is not completely
	doc'ed
In-Reply-To: <1256073188.35.0.768583079115.issue7178@psf.upfronthosting.co.za>
Message-ID: <1256073188.35.0.768583079115.issue7178@psf.upfronthosting.co.za>


New submission from kuhnsjohn <kuhnsjohn at gmail.com>:

it says: "Pass 0 to switch buffering off (only allowed in binary mode),
1 to set line buffering, and an integer > 1 for full buffering."

The last section should say something like: "and an integer > 1 to
specify the buffer size for full buffering."

----------
assignee: georg.brandl
components: Documentation
messages: 94300
nosy: georg.brandl, kuhnsjohn
severity: normal
status: open
title: open function's buffering parameter is not completely doc'ed
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7178>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:23:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 21:23:43 +0000
Subject: [issue6845] Restart support in binary upload for ftplib
In-Reply-To: <1256057441.06.0.681834344356.issue6845@psf.upfronthosting.co.za>
Message-ID: <1256074054.6223.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think that a non-digit REST argument is an error. But I've tested some
> ftp servers and they don't return an error code, they just set REST to 0
> and return some OK code. Finally, ftplib doesn't check that, so if
> someone accidentally passes a non-digit argument it could be a difficult
> bug to spot.

What I mean is that integer arguments should be accepted as well, since
that's what is logical to produce.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:56:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Oct 2009 21:56:18 +0000
Subject: [issue7178] open function's buffering parameter is not completely
	doc'ed
In-Reply-To: <1256073188.35.0.768583079115.issue7178@psf.upfronthosting.co.za>
Message-ID: <1256075778.41.0.971379489183.issue7178@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r75572.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7178>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:09:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2009 22:09:24 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1256076564.79.0.838830750055.issue1722344@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch was committed in trunk, py3k and 3.1. Waiting for 2.6 to be
unfrozen before I commit it there too.

----------
stage: commit review -> committed/rejected
status: open -> pending
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:46:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2009 22:46:56 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1256078816.87.0.849123945052.issue7119@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thinking about this further, it seems to me that it is in fact more
important that turning a message into a string produces the same result
no matter how many times it is called on the same (otherwise unmutated)
object than that it avoid mutating the object tree itself.  (This is
called idempotence and it is an important interface concept in certain
circumstances, and I think this is one of them).

The documentation should make the expectations clear, however.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________

From report at bugs.python.org  Wed Oct 21 02:41:27 2009
From: report at bugs.python.org (Thomas Klausner)
Date: Wed, 21 Oct 2009 00:41:27 +0000
Subject: [issue7179] Unportable test(1) construct
In-Reply-To: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>
Message-ID: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>


New submission from Thomas Klausner <tk at giga.or.at>:

Mac/BuildScript/scripts/postflight.patch-profile and Misc/build.sh
contain the unportable bash(1) "==" comparison operator for test(1). It
is not supported by most other shells or even test(1) from GNU
coreutils. Please use "=" instead.

----------
components: Build
files: test.1.patch
keywords: patch
messages: 94305
nosy: wiz
severity: normal
status: open
title: Unportable test(1) construct
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15170/test.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7179>
_______________________________________

From report at bugs.python.org  Wed Oct 21 02:44:07 2009
From: report at bugs.python.org (Thomas Klausner)
Date: Wed, 21 Oct 2009 00:44:07 +0000
Subject: [issue7179] Unportable test(1) construct
In-Reply-To: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>
Message-ID: <1256085847.03.0.331278348359.issue7179@psf.upfronthosting.co.za>


Thomas Klausner <tk at giga.or.at> added the comment:

That's against python-2.6.3. I see that Misc/build.sh automagically
linked from this bug report doesn't have this problem any longer (though
the other file still does).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7179>
_______________________________________

From report at bugs.python.org  Wed Oct 21 03:04:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Oct 2009 01:04:56 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1256087096.1.0.973975616951.issue7119@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: georg.brandl -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________

From report at bugs.python.org  Wed Oct 21 04:51:57 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Oct 2009 02:51:57 +0000
Subject: [issue7179] Unportable test(1) construct
In-Reply-To: <1256085687.72.0.300279109357.issue7179@psf.upfronthosting.co.za>
Message-ID: <1256093517.41.0.266095460129.issue7179@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7179>
_______________________________________

From report at bugs.python.org  Wed Oct 21 08:43:17 2009
From: report at bugs.python.org (Kevin Grant)
Date: Wed, 21 Oct 2009 06:43:17 +0000
Subject: [issue7180] "pydoc -k" can generate AttributeError on Mac OS X
In-Reply-To: <1256107397.12.0.192527244395.issue7180@psf.upfronthosting.co.za>
Message-ID: <1256107397.12.0.192527244395.issue7180@psf.upfronthosting.co.za>


New submission from Kevin Grant <kmg at mac.com>:

Running "pydoc -k ..." with a query string will end with a Python AttributeError while looking for Carbon.File.FSSpecType.

I was using /usr/bin/pydoc on Mac OS X Snow Leopard, which is from Python 2.6.1.

It appears that any query will produce a similar error, but here is one case:

  % pydoc -k example
  xxsubtype - xxsubtype is an example module showing how to subtype builtin types from C.
  doctest - Module doctest -- a framework for running examples in docstrings.
  Traceback (most recent call last):
    File "/usr/bin/pydoc2.6", line 7, in <module>
      pydoc.cli()
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 2216, in cli
      apropos(val)
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 1911, in apropos
      ModuleScanner().run(callback, key)
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 1876, in run
      for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pkgutil.py", line 110, in walk_packages
      __import__(name)
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-
scriptpackages/CodeWarrior/__init__.py", line 8, in <module>
      import aetools
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aetools.py", line 36, in <module>
      from aepack import packkey, pack, unpack, coerce, AEDescType
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aepack.py", line 61, in <module>
      FSSType = Carbon.File.FSSpecType
  AttributeError: 'module' object has no attribute 'FSSpecType'



A solution would appear to be as follows:

Since Carbon.File no longer defines FSSpecType, perhaps aepack.py should no longer support it.  This would require removing 
the definition from aepack.py:61, as well as the case in the pack() routine (at aepack.py:88-89) that uses FSSType.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 94307
nosy: kmgrant, ronaldoussoren
severity: normal
status: open
title: "pydoc -k" can generate AttributeError on Mac OS X
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7180>
_______________________________________

From report at bugs.python.org  Wed Oct 21 09:18:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Oct 2009 07:18:09 +0000
Subject: [issue7170] subclasses of (some) built-in types are not weakref-able
In-Reply-To: <1255988888.99.0.764366839405.issue7170@psf.upfronthosting.co.za>
Message-ID: <1256109489.16.0.918454304611.issue7170@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r75580, r75581.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7170>
_______________________________________

From report at bugs.python.org  Wed Oct 21 09:24:23 2009
From: report at bugs.python.org (jmb)
Date: Wed, 21 Oct 2009 07:24:23 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1256109863.97.0.99047039585.issue2889@psf.upfronthosting.co.za>


jmb <jeberger at free.fr> added the comment:

I've built a package for python 2.6 using a slightly modified version of
this patch. I've uploaded it here: http://jeberger.free.fr/python/

I'm attaching my version of the patch here. I had to make two
modifications for it to work:
- Change all references to _ISPAD into _PAD (obviously this needs to be
done better since what I did will break the ncurses compatibility);
- Change "(long) (n << 8)" into "COLOR_PAIR (n)". This should be
compatible between curses implementations.

With this package, I've been able to run the Mercurial "crecord"
extension on Windows.

----------
Added file: http://bugs.python.org/file15171/python-pdcurses-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Wed Oct 21 14:50:22 2009
From: report at bugs.python.org (Cristian Romanescu)
Date: Wed, 21 Oct 2009 12:50:22 +0000
Subject: [issue7181] No logging when two loggers with same qualname
In-Reply-To: <1256129422.09.0.787842545127.issue7181@psf.upfronthosting.co.za>
Message-ID: <1256129422.09.0.787842545127.issue7181@psf.upfronthosting.co.za>


New submission from Cristian Romanescu <cristiroma at yahoo.com>:

Hello, everyone. I think I have found a bug in the python logging module
when configured via fileConfig

Scenario 1:
When using the configuration file attached to this ticket and test case
below, there should be logging in three places: 
* console (info and error)
* 'butterfly.log' (info and error)
* 'butterfly-error (error)

In third no output is ever written.

Scenario 2:
Another odd thing is that when using
keys=root,errorLogger,normalLogger - root and normalLogger works
correct, errorLogger not,
but if I use keys=root,normalLogger,errorLogger - root and errorLogger
works fine, normalLogger not. So there is a link between order of logger
definition?

Scenarion 3:
If I change to one of the loggers qualname=butterfly.test then both
loggers works fine.

Platform: Windows XP + SP2
Python: 2.5.4

Test case:
import logging
from logging import config

config.fileConfig('logging.cristiroma.config')
log = logging.getLogger('butterfly.test')
log.info('info')
log.error('error')

Output:

Console:
  2009-10-21 15:38:48 INFO butterfly.test info
  2009-10-21 15:38:48 ERROR butterfly.test error

butterfly.log:
  2009-10-21 15:40:32 INFO butterfly.test test.py:<module>:7 info
  2009-10-21 15:40:32 ERROR butterfly.test test.py:<module>:8 error

butterfly-error.log:
  Nothing

P.S. This is my first bug submission, tried to google about it. Please
don't shoot.

Regards,
Cristian.

----------
components: Library (Lib), Windows
files: logging.cristiroma.config
messages: 94310
nosy: cristiroma
severity: normal
status: open
title: No logging when two loggers with same qualname
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15172/logging.cristiroma.config

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7181>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:02:20 2009
From: report at bugs.python.org (Wolodja Wentland)
Date: Wed, 21 Oct 2009 15:02:20 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1256137340.1.0.180468828186.issue1293741@psf.upfronthosting.co.za>


Wolodja Wentland <wentland at cl.uni-heidelberg.de> added the comment:

Here is some more information.

--- snip ---

Normal behaviour
================

$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=POSIX
LC_TIME=en_GB.UTF-8
LC_COLLATE=en_GB.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=de_DE.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=
$ python2.6
Python 2.6.3 (r263:75183, Oct  6 2009, 17:19:56) 
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print '??'
??
>>> print u'??'
??
>>> '??'
'\xe7\xbc\xba\xe9\x99\xb7'
>>> u'??'
u'\u7f3a\u9677'
>>> '??'.decode('utf8')
u'\u7f3a\u9677'
>>> u'\u7f3a\u9677'
u'\u7f3a\u9677'
>>> 
$ cat unicode_bug.py 
#!/usr/bin/env python
# -*- coding: UTF-8 -*-

def print_string():
    """
    >>> print '??'
    ??
    """
    pass

def print_unicode():
    """
    >>> print u'??'
    ??
    """
    pass

def string_repr():
    """
    >>> '??'
    '\xe7\xbc\xba\xe9\x99\xb7'
    """
    pass

def unicode_repr():
    """
    >>> u'??'
    u'\u7f3a\u9677'
    """
    pass

def decode():
    """
    >>> '??'.decode('utf8')
    u'\u7f3a\u9677'
    """
    pass

def unicode_escape_repr():
    """
    >>> u'\u7f3a\u9677'
    u'\u7f3a\u9677'
    """
    pass

if __name__ == "__main__":
    import doctest
    doctest.testmod()

$ python2.5 unicode_bug.py 
/usr/lib/python2.5/doctest.py:1460: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
/usr/lib/python2.5/doctest.py:1480: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
Traceback (most recent call last):
  File "unicode_bug.py", line 48, in <module>
    doctest.testmod()
  File "/usr/lib/python2.5/doctest.py", line 1815, in testmod
    runner.run(test)
  File "/usr/lib/python2.5/doctest.py", line 1361, in run
    return self.__run(test, compileflags, out)
  File "/usr/lib/python2.5/doctest.py", line 1277, in __run
    self.report_failure(out, test, example, got)
  File "/usr/lib/python2.5/doctest.py", line 1141, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
  File "/usr/lib/python2.5/doctest.py", line 1565, in output_difference
    return 'Expected:\n%sGot:\n%s' % (_indent(want), _indent(got))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 14:
ordinal not in range(128)

$ python2.6 unicode_bug.py 
/usr/local/lib/python2.6/doctest.py:1475: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
/usr/local/lib/python2.6/doctest.py:1495: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
Traceback (most recent call last):
  File "unicode_bug.py", line 48, in <module>
    doctest.testmod()
  File "/usr/local/lib/python2.6/doctest.py", line 1830, in testmod
    runner.run(test)
  File "/usr/local/lib/python2.6/doctest.py", line 1374, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.6/doctest.py", line 1290, in __run
    self.report_failure(out, test, example, got)
  File "/usr/local/lib/python2.6/doctest.py", line 1154, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
  File "/usr/local/lib/python2.6/doctest.py", line 1580, in
output_difference
    return 'Expected:\n%sGot:\n%s' % (_indent(want), _indent(got))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 14:
ordinal not in range(128)

$ nosetests -V
nosetests version 0.11.1

$ nosetests --with-doctest -v unicode_bug.py 
Doctest: unicode_bug.decode ... ok
Doctest: unicode_bug.print_string ... ok
Doctest: unicode_bug.print_unicode ...
/usr/local/lib/python2.6/doctest.py:1475: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
/usr/local/lib/python2.6/doctest.py:1495: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
ERROR
Doctest: unicode_bug.string_repr ... FAIL
Doctest: unicode_bug.unicode_escape_repr ... ok
Doctest: unicode_bug.unicode_repr ... FAIL

======================================================================
ERROR: Doctest: unicode_bug.print_unicode
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2140, in runTest
    test, out=new.write, clear_globs=False)
  File "/usr/local/lib/python2.6/doctest.py", line 1374, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.6/doctest.py", line 1290, in __run
    self.report_failure(out, test, example, got)
  File "/usr/local/lib/python2.6/doctest.py", line 1154, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
  File "/usr/local/lib/python2.6/doctest.py", line 1580, in
output_difference
    return 'Expected:\n%sGot:\n%s' % (_indent(want), _indent(got))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 14:
ordinal not in range(128)

======================================================================
FAIL: Doctest: unicode_bug.string_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2145, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for unicode_bug.string_repr
  File "/home/babilen/test/unicode_bug.py", line 18, in string_repr

----------------------------------------------------------------------
File "/home/babilen/test/unicode_bug.py", line 20, in
unicode_bug.string_repr
Failed example:
    '??'
Expected:
    '??'
Got:
    '\xe7\xbc\xba\xe9\x99\xb7'


======================================================================
FAIL: Doctest: unicode_bug.unicode_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2145, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for unicode_bug.unicode_repr
  File ".../unicode_bug.py", line 25, in unicode_repr

----------------------------------------------------------------------
File ".../unicode_bug.py", line 27, in unicode_bug.unicode_repr
Failed example:
    u'??'
Expected:
    u'\u7f3a\u9677'
Got:
    u'\xe7\xbc\xba\xe9\x99\xb7'


----------------------------------------------------------------------
Ran 6 tests in 0.011s

FAILED (errors=1, failures=2)

--- snip ---

unicode_literals
================

$ python2.6
Python 2.6.3 (r263:75183, Oct  6 2009, 17:19:56) 
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import unicode_literals
>>> print '??'
??
>>> print u'??'
??
>>> '??'
u'\u7f3a\u9677'
>>> u'??'
u'\u7f3a\u9677'
>>> '??'.decode('utf8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-1: ordinal not in range(128)
>>> u'\u7f3a\u9677'
u'\u7f3a\u9677'

$ cat unicode_bug_literals.py
#!/usr/bin/env python
# -*- coding: UTF-8 -*-

from __future__ import unicode_literals

def print_string():
    """
    >>> print '??'
    ??
    """
    pass

def print_unicode():
    """
    >>> print u'??'
    ??
    """
    pass

def string_repr():
    """
    >>> '??'
    u'\u7f3a\u9677'
    """
    pass

def unicode_repr():
    """
    >>> u'??'
    u'\u7f3a\u9677'
    """
    pass

def unicode_escape_repr():
    """
    >>> u'\u7f3a\u9677'
    u'\u7f3a\u9677'
    """
    pass

if __name__ == "__main__":
    import doctest
    doctest.testmod()

$ python2.6 unicode_bug_literals.py
Traceback (most recent call last):
  File "unicode_bug_literals.py", line 43, in <module>
    doctest.testmod()
  File "/usr/local/lib/python2.6/doctest.py", line 1830, in testmod
    runner.run(test)
  File "/usr/local/lib/python2.6/doctest.py", line 1374, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.6/doctest.py", line 1290, in __run
    self.report_failure(out, test, example, got)
  File "/usr/local/lib/python2.6/doctest.py", line 1154, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
UnicodeEncodeError: 'ascii' codec can't encode characters in position
157-158: ordinal not in range(128)

$ nosetests --with-doctest -v unicode_bug_literals.py 
Doctest: unicode_bug_literals.print_string ... ok
Doctest: unicode_bug_literals.print_unicode ... ok
Doctest: unicode_bug_literals.string_repr ... FAIL
Doctest: unicode_bug_literals.unicode_escape_repr ... FAIL
Doctest: unicode_bug_literals.unicode_repr ... FAIL

======================================================================
FAIL: Doctest: unicode_bug_literals.string_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2145, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: <unprintable AssertionError object>

======================================================================
FAIL: Doctest: unicode_bug_literals.unicode_escape_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2145, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: <unprintable AssertionError object>

======================================================================
FAIL: Doctest: unicode_bug_literals.unicode_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2145, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: <unprintable AssertionError object>

----------------------------------------------------------------------
Ran 5 tests in 0.011s

FAILED (failures=3)

--- snip ---

With doctest.unicode-2.patch
============================

$ nosetests --with-doctest -v unicode_bug.py 
Doctest: unicode_bug.decode ... ok
Doctest: unicode_bug.print_string ... ok
Doctest: unicode_bug.print_unicode ...
/usr/local/lib/python2.6/doctest.py:1480: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
/usr/local/lib/python2.6/doctest.py:1500: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  if got == want:
ERROR
Doctest: unicode_bug.string_repr ... ERROR
Doctest: unicode_bug.unicode_escape_repr ... ok
Doctest: unicode_bug.unicode_repr ... ERROR

======================================================================
ERROR: Doctest: unicode_bug.print_unicode
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2150, in runTest
    clear_globs=False)
  File "/usr/local/lib/python2.6/doctest.py", line 1379, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.6/doctest.py", line 1291, in __run
    self.report_failure(out, test, example, got)
  File "/usr/local/lib/python2.6/doctest.py", line 1155, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
  File "/usr/local/lib/python2.6/doctest.py", line 1585, in
output_difference
    return 'Expected:\n%sGot:\n%s' % (_indent(want), _indent(got))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 14:
ordinal not in range(128)

======================================================================
ERROR: Doctest: unicode_bug.string_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2150, in runTest
    clear_globs=False)
  File "/usr/local/lib/python2.6/doctest.py", line 1379, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.6/doctest.py", line 1291, in __run
    self.report_failure(out, test, example, got)
  File "/usr/local/lib/python2.6/doctest.py", line 1155, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
  File "/usr/local/lib/python2.6/doctest.py", line 2149, in <lambda>
    test, out=lambda x: new.write(x.encode(output_encoding)),
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position
170: ordinal not in range(128)

======================================================================
ERROR: Doctest: unicode_bug.unicode_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2150, in runTest
    clear_globs=False)
  File "/usr/local/lib/python2.6/doctest.py", line 1379, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.6/doctest.py", line 1291, in __run
    self.report_failure(out, test, example, got)
  File "/usr/local/lib/python2.6/doctest.py", line 1155, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
  File "/usr/local/lib/python2.6/doctest.py", line 2149, in <lambda>
    test, out=lambda x: new.write(x.encode(output_encoding)),
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position
172: ordinal not in range(128)

----------------------------------------------------------------------
Ran 6 tests in 0.010s

FAILED (errors=3)

$ nosetests --with-doctest -v unicode_bug_literals.py 
Doctest: unicode_bug_literals.print_string ... ok
Doctest: unicode_bug_literals.print_unicode ... ok
Doctest: unicode_bug_literals.string_repr ... FAIL
Doctest: unicode_bug_literals.unicode_escape_repr ... FAIL
Doctest: unicode_bug_literals.unicode_repr ... FAIL

======================================================================
FAIL: Doctest: unicode_bug_literals.string_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2155, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for unicode_bug_literals.string_repr
  File "/home/babilen/test/unicode_bug_literals.py", line 20, in string_repr

----------------------------------------------------------------------
File "/home/babilen/test/unicode_bug_literals.py", line 22, in
unicode_bug_literals.string_repr
Failed example:
    '??'
Expected:
    u'??'
Got:
    u'\u7f3a\u9677'


======================================================================
FAIL: Doctest: unicode_bug_literals.unicode_escape_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2155, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
unicode_bug_literals.unicode_escape_repr
  File "/home/babilen/test/unicode_bug_literals.py", line 34, in
unicode_escape_repr

----------------------------------------------------------------------
File "/home/babilen/test/unicode_bug_literals.py", line 36, in
unicode_bug_literals.unicode_escape_repr
Failed example:
    u'??'
Expected:
    u'??'
Got:
    u'\u7f3a\u9677'


======================================================================
FAIL: Doctest: unicode_bug_literals.unicode_repr
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/doctest.py", line 2155, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for unicode_bug_literals.unicode_repr
  File "/home/babilen/test/unicode_bug_literals.py", line 27, in
unicode_repr

----------------------------------------------------------------------
File "/home/babilen/test/unicode_bug_literals.py", line 29, in
unicode_bug_literals.unicode_repr
Failed example:
    u'??'
Expected:
    u'??'
Got:
    u'\u7f3a\u9677'


----------------------------------------------------------------------
Ran 5 tests in 0.009s

FAILED (failures=3)

--- snip ---

If you need further information do not hesitate to contact me.

with kind regards

    Wolodja Wentland

----------
nosy: +babilen
Added file: http://bugs.python.org/file15173/unicode_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:08:41 2009
From: report at bugs.python.org (Wolodja Wentland)
Date: Wed, 21 Oct 2009 15:08:41 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1256137721.81.0.807487026107.issue1293741@psf.upfronthosting.co.za>


Changes by Wolodja Wentland <wentland at cl.uni-heidelberg.de>:


Added file: http://bugs.python.org/file15174/unicode_bug_literals.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:20:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Oct 2009 15:20:44 +0000
Subject: [issue7181] No logging when two loggers with same qualname
In-Reply-To: <1256129422.09.0.787842545127.issue7181@psf.upfronthosting.co.za>
Message-ID: <1256138444.24.0.565260243251.issue7181@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7181>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:24:54 2009
From: report at bugs.python.org (Stac)
Date: Wed, 21 Oct 2009 15:24:54 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256138694.48.0.947497824967.issue1235@psf.upfronthosting.co.za>


Stac <stac_agenais at yahoo.fr> added the comment:

Hello,

I am new to Python issues tracker. I had the error described above. I
worked on it.

I was not able to solve the issue only using subprocess. The command has
to be correctly formated (with the double quotes).

I corrected the cmdline definition as described first and migrated from
popen2 and popen3 to subprocess. I don't think I have the rights to
commit any code so I send the modified file.

Don't hesitate to tell me if you want me do to more.
Regards,

Stac

PS : For information, the attached file correct the following error :

localhost - - [21/Oct/2009 17:20:52] "POST /cgi/test.py HTTP/1.1" 200 -
localhost - - [21/Oct/2009 17:20:52] command:
C:\Produits\Python26\python.exe -u C:\Documents and
Settings\stac\workspace\PyToolkit\src\network\cgi\test.py ""
localhost - - [21/Oct/2009 17:20:53] C:\Produits\Python26\python.exe:
can't open file 'C:\Documents': [Errno 2] No such file or directory

Now you have :
localhost - - [21/Oct/2009 16:48:46] "POST /cgi/test.py HTTP/1.1" 200 -
localhost - - [21/Oct/2009 16:48:46] command:
C:\Produits\Python26\python.exe -u "C:\Documents and
Settings\stac\workspace\PyToolkit\src\network\cgi\test.py" ""
localhost - - [21/Oct/2009 16:48:47] CGI script exited OK

----------
nosy: +stac
versions:  -Python 3.0
Added file: http://bugs.python.org/file15175/MyCGIHTTPServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:03:48 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 21 Oct 2009 17:03:48 +0000
Subject: [issue7181] No logging when two loggers with same qualname
In-Reply-To: <1256129422.09.0.787842545127.issue7181@psf.upfronthosting.co.za>
Message-ID: <1256144628.78.0.452948540137.issue7181@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

You have made a mistake in your configuration. You only have one logger,
named "butterfly", but this wrongly appears twice in your configuration.

Remove the errorLogger key and section entirely, then add errorHandler
to the handlers of normalLogger. Because the errorFileHandler has a
level of ERROR, only ERRORS and greater will be written to the error file.

Tested with changed file on Python 2.5.2 under Windows, performs as
expected. Closing this issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7181>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:17:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Oct 2009 17:17:42 +0000
Subject: [issue7177] Unclear warning for subprocess.call
In-Reply-To: <1256070005.74.0.0266256477403.issue7177@psf.upfronthosting.co.za>
Message-ID: <1256145462.27.0.437889992794.issue7177@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Assigning to Philip who added the warning.

----------
assignee: georg.brandl -> pjenvey
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7177>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:49:02 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 21 Oct 2009 17:49:02 +0000
Subject: [issue7182] For non-debug builds,
	the cygwinccompiler.py should define NDEBUG
In-Reply-To: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>
Message-ID: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Currently, msvccompiler.py defines NDEBUG for non-debug builds.  Unix
builds do as well, via python-config.  However, cygwinccompiler.py does not.

----------
assignee: tarek
components: Distutils
messages: 94315
nosy: stutzbach, tarek
severity: normal
status: open
title: For non-debug builds, the cygwinccompiler.py should define NDEBUG
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7182>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:02:41 2009
From: report at bugs.python.org (David Bonner)
Date: Wed, 21 Oct 2009 18:02:41 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1256148161.51.0.232001020115.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

Hrm...yeah, I should probably be setting it to closed as soon as
BZ2_bzReadClose() returns, and then back to open once BZ2_bzReadOpen
succeeds.  Wasn't intentional...thanks for the catch.  You guys need a
new patch with that change in it?

I'll try and get a 2.7 patch done and uploaded in a day or two.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:27:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Oct 2009 18:27:47 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1256149667.65.0.915230798822.issue7165@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well this is in the CGI implementation, and it's reasonable to assume
that CGI will only be used with a real stream. Besides, the encoding
used with stdout must be the xmlrpc encoding (probably utf-8), not the
default encoding of standard streams on the system, which means direct
access to the underlying binary stream must be possible.

(however, _marshaled_dispatch() is quite strange in that it accepts str
but returns bytes)

I propose to fix test_xmlrpc instead so that it uses a BytesIO wrapped
in a TextIOWrapper. Patch included.

----------
keywords: +patch
nosy: +loewis, pitrou
Added file: http://bugs.python.org/file15176/test_xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:28:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Oct 2009 18:28:26 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1256149706.48.0.338733784046.issue1625@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A new patch will make it more likely that it will actually get applied :)

Thanks for your work on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Wed Oct 21 21:28:43 2009
From: report at bugs.python.org (Dan)
Date: Wed, 21 Oct 2009 19:28:43 +0000
Subject: [issue1662581] the re module can perform poorly: O(2**n) versus
	O(n**2)
Message-ID: <1256153323.77.0.147473289231.issue1662581@psf.upfronthosting.co.za>


Dan <witten at torsion.org> added the comment:

Here's an easy way to trigger the poor performance. Tested with 2.5,
2.6, and 2.7:

re.compile( '(\s+.*)*x' ).search( 'a ' * 30 )

----------
nosy: +witten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662581>
_______________________________________

From report at bugs.python.org  Wed Oct 21 21:48:20 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Wed, 21 Oct 2009 19:48:20 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1256154500.73.0.354928896566.issue6978@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

PythonTidy encounters this problem.

o http://lacusveris.com/PythonTidy/PythonTidy.python

It is unable correctly to render line 694 of test_grammar.py in the
Python Test Suite:

    d[1,] = 2

becomes:

    d[1] = 2

because the *compiler* module does not return an abstract syntax tree
containing a tuple for the subscript.

----------
nosy: +ChuckRhode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

From report at bugs.python.org  Wed Oct 21 22:09:12 2009
From: report at bugs.python.org (David Bonner)
Date: Wed, 21 Oct 2009 20:09:12 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1256155752.1.0.307932026905.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

Understandable.  New patch attached.

----------
Added file: http://bugs.python.org/file15177/py3k_bz2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Wed Oct 21 22:24:27 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 21 Oct 2009 20:24:27 +0000
Subject: [issue1662581] the re module can perform poorly: O(2**n) versus
	O(n**2)
Message-ID: <1256156667.42.0.783219620595.issue1662581@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I'm still tinkering with my regex engine (issue #2636).

Some timings:

re.compile(r'(\s+.*)*x').search('a ' * 25)
20.23secs

regex.compile(r'(\s+.*)*x').search('a ' * 25)
0.10secs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662581>
_______________________________________

From report at bugs.python.org  Wed Oct 21 22:34:44 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 21 Oct 2009 20:34:44 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1256157284.67.0.296960065497.issue7077@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and py3k (r75586). Please verify in your
environment and post your results here.

There are no plans to backport this to 2.6 or earlier.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7077>
_______________________________________

From report at bugs.python.org  Wed Oct 21 22:43:06 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Oct 2009 20:43:06 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1256157786.67.0.228394098143.issue6324@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Wed Oct 21 22:45:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Oct 2009 20:45:42 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1256157942.92.0.979742820391.issue6690@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Wed Oct 21 23:11:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Oct 2009 21:11:08 +0000
Subject: [issue4967] Bugs in _ssl object read() when a buffer is specified
In-Reply-To: <1232159812.52.0.781690409094.issue4967@psf.upfronthosting.co.za>
Message-ID: <1256159468.99.0.955866898115.issue4967@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, there is nothing to backport since the trunk version doesn't handle
bytearrays in the first place!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4967>
_______________________________________

From report at bugs.python.org  Wed Oct 21 23:38:35 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 21 Oct 2009 21:38:35 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1256161115.62.0.731964713289.issue6672@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Wed Oct 21 23:51:18 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 21 Oct 2009 21:51:18 +0000
Subject: [issue7182] For non-debug builds,
	the cygwinccompiler.py should define NDEBUG
In-Reply-To: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>
Message-ID: <1256161878.51.0.532933180071.issue7182@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Posix build system read flags from makefile.
Configure script add -DNDEBUG to OPT flag. So why cygwinccompiler.py has
to set this ?
Next cygwinccompiler currently is not used in python build system.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7182>
_______________________________________

From report at bugs.python.org  Wed Oct 21 23:58:15 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 21 Oct 2009 21:58:15 +0000
Subject: [issue7182] For non-debug builds,
	the cygwinccompiler.py should define NDEBUG
In-Reply-To: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>
Message-ID: <1256162295.35.0.960313329956.issue7182@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Sorry, I should have said the mingw32 compiler, which is contained in
cygwincompiler.py  The mingw32 compiler is a free compiler compatible
with MSVC.  Since it's used with the Windows version of python, there is
no configure script.

I noticed this when trying to build an extension module with "python
setup.py build -c mingw32", using the Windows (not cygwin) version of
python.  The extension module failed to compile because had a line like
this:
  assert(my_struct->debug_only_field);

where "debug_only_field" is only declared if Py_DEBUG is set.  When
NDEBUG is set, the assert disappears and the compile works as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7182>
_______________________________________

From report at bugs.python.org  Thu Oct 22 00:08:15 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 21 Oct 2009 22:08:15 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1256162895.53.0.457757486394.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Apparently the extra menu entries are related to an Appkit bug on Leopard 
that Tk-Cocoa picks up; the bug is not present on Snow Leopard and won't 
be fixed on Leopard. As a result, I've closed the SF bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Thu Oct 22 01:22:37 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 21 Oct 2009 23:22:37 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

According to 
https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 , 
Python 2.6.3 stopped working for something that Python 2.6.2 worked for, 
involving Boost.

Andrew Mitchell looked at the Python 2.6.3 release notes, saw 
http://bugs.python.org/issue5890 which was fixed by 
http://svn.python.org/view/python/branches/release26-
maint/Objects/descrobject.c?r1=71756&r2=72302&pathrev=72302 .  Could this 
patch be causing this problem?

----------
components: Interpreter Core
messages: 94329
nosy: zooko
severity: normal
status: open
title: did 2.6.3 regress for some uses of the __doc__ property?
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 01:34:19 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 21 Oct 2009 23:34:19 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256168059.19.0.0595192222298.issue7183@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think this is caused by the fix for bug 5890 and isn't a regression.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 02:16:20 2009
From: report at bugs.python.org (Richard Jones)
Date: Thu, 22 Oct 2009 00:16:20 +0000
Subject: [issue7184] build failures on Snow Leopard
In-Reply-To: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>
Message-ID: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>


New submission from Richard Jones <richardjones at optushome.com.au>:

I'm using python 2.6 maint SVN r75588 and get the attached build log
when I run:

  configure --enable-framework
  make

Failed to build these modules:
_curses            _curses_panel      _tkinter        
readline

----------
components: Build
files: python-r75588-build.log
messages: 94331
nosy: richard
severity: normal
status: open
title: build failures on Snow Leopard
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file15178/python-r75588-build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7184>
_______________________________________

From report at bugs.python.org  Thu Oct 22 03:47:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 22 Oct 2009 01:47:11 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1256176031.71.0.800071253494.issue6978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch should have a test.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

From report at bugs.python.org  Thu Oct 22 04:02:07 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 22 Oct 2009 02:02:07 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256176927.59.0.510333476921.issue7183@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Apparently this affects more than just Boost.  lifeless (Robert Collins)
tells me that "__doc__ becoming readonly buggered some code of ours in
bzr too, IIRC".

He thinks it was in pure Python (i.e. not extension code).  Does anybody
have a pure Python reproducible example?

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 08:18:54 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Oct 2009 06:18:54 +0000
Subject: [issue7184] build failures on Snow Leopard
In-Reply-To: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>
Message-ID: <1256192334.62.0.63516289038.issue7184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Building a batteries-included framework on OS X is not a simple task, 
especially on 10.6 Snow Leopard where the system default is to build 64-
bit archs.  There are several known build issues with building a 
complete framework on 10.6.  It's not clear what your intentions are. If 
you want a 64-bit build with everything included, you'll need to supply 
a 64-bit version of readline (which is not included in OS X) and, prior 
to building, you may need to delete any already installed python.org (or 
other 3rd-party) version of python2.6 in 
/Library/Frameworks/Python.framework/Version/2.6: you may end up with 
dynamic linking to a 32-bit version of the ncurses libraries from there.  
And Tkinter and Tk are problematic: there are some unresolved problems 
using the 64-bit Apple-supplied Tk in 10.6.  If you don't need ncurses 
et al, just ignore the build errors.  If you do need them, your best bet 
is to use or adapt the OS X installer build script, 
Mac/BuildScript/build-installer.py, and/or to stick with a 32-bit 
universal build.  There are still a number of rough edges with 64-bit 
builds.

There is perhaps one new wrinkle here: since you didn't specify --with-
universal-archs to configure, configure *thinks* it is building for 32-
bit and defaults to not supplying -arch to the gcc commands it 
generates; on 10.6, though, it looks like the absence of -arch causes a 
64-bit build to take place.  To get around that, configure may need to 
always supply -arch.  Also, I'm guessing that you didn't supply a 
deployment target which results in the somewhat confusing macosx-10.4-
i386 directory names and might have other implications.  (These 
observations are just from a quick look at your build output. This 
should be looked at more thoroughly when time is available.)

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7184>
_______________________________________

From report at bugs.python.org  Thu Oct 22 08:20:12 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Thu, 22 Oct 2009 06:20:12 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1256192412.78.0.801116991702.issue6324@psf.upfronthosting.co.za>


Anthony Foglia <afoglia at gmail.com> added the comment:

I've added Python 2.7 to the list of versions.  The development docs
have the same issue.

Let me try another stab at what the docs should say.  Following the
suggestion to add it to 3.3.5, perhaps it should be:

"
object.__contains__(self, item)
    Called to implement membership test operators. Should return true if
item is in self, false otherwise. For mapping objects, this should
consider the keys of the mapping rather than the values or the key-item
pairs.

    If __contains__ is not provided but __iter__ is provided, the
membership test "x in y" is true if and only if there is a value z
reachable by iterating iter(y) before iter(y) throws a StopIteration
exception.  (If any other exception is raised, it is as if
in raised that exception).

    If neither __contains__ nor __iter__ are provided but __getitem__ is
provided, the membership test "x in y" is true if and only if there is a
non-negative integer index i such that x == y[i], and all lower integer
indices do not raise IndexError exception. (If any other exception is
raised, it is as if in raised that exception).
"

I worry that this is becoming more a description of "in" rather than
__contains__. 

Either way, the last sentence in paragraph 6 of section 5.9 should refer
not just to 3.3.1 (Basic Customization) but also 3.3.5 (Emulating
Container Types).  The latter is where __contains__, __iter__ and
__getitem__ are defined.  Perhaps the new wording should be, "You can
control comparison behavior of objects of non-built-in types by defining
rich comparison methods like __gt__(), described in section Basic
customization, and the membership test method __contains__(), described
in section Emulating container types."

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Thu Oct 22 08:37:20 2009
From: report at bugs.python.org (Derk Drukker)
Date: Thu, 22 Oct 2009 06:37:20 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256193440.52.0.884698720979.issue1235@psf.upfronthosting.co.za>


Derk Drukker <derk.drukker at gmail.com> added the comment:

Salut,

Note that in py3k, CGIHTTPRequestHandler (Lib/http/server.py) already
switched to using subprocess.

AFAICT, you didn't actually change cmdline, and so the problem remains.

----------
nosy: +drukker
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:00:42 2009
From: report at bugs.python.org (Stac)
Date: Thu, 22 Oct 2009 07:00:42 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256194842.44.0.87620633752.issue1235@psf.upfronthosting.co.za>


Stac <stac_agenais at yahoo.fr> added the comment:

Oups,

I really feel sorry.
Well here is a version with the modified cmdline.
I will check how the migration was done in py3k. 

Just a quick question : why the changes done in py3k was not reported to
py2.x ?

Regards,

Stac

----------
Added file: http://bugs.python.org/file15179/MyCGIHTTPServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:30:20 2009
From: report at bugs.python.org (Stac)
Date: Thu, 22 Oct 2009 07:30:20 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256196620.63.0.54134358739.issue1235@psf.upfronthosting.co.za>


Stac <stac_agenais at yahoo.fr> added the comment:

Ok,

I corrected the two versions.
Now the one for py2.x is closer to the fix for py3k.
You'll find below the fixed code for both version.

Regards,

Stac

----------
Added file: http://bugs.python.org/file15180/fix.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Thu Oct 22 10:28:50 2009
From: report at bugs.python.org (Derk Drukker)
Date: Thu, 22 Oct 2009 08:28:50 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256200130.26.0.919014270186.issue1235@psf.upfronthosting.co.za>


Derk Drukker <derk.drukker at gmail.com> added the comment:

The original problem reported concerned spaces in the path of the python
executable.  So interp needs to be in quotes, as well (as Andy already
suggested).  I've created a patch against the latest py3k, which I've
confirmed works and fixes this issue.

I'm not a core developer, so I don't know why it wasn't backported. I
don't know if this will make it into 2.6. Maybe trunk?

----------
keywords: +patch
Added file: http://bugs.python.org/file15181/fix-issue1235-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Thu Oct 22 11:57:11 2009
From: report at bugs.python.org (Stac)
Date: Thu, 22 Oct 2009 09:57:11 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256205431.3.0.865634634015.issue1235@psf.upfronthosting.co.za>


Changes by Stac <stac_agenais at yahoo.fr>:


Removed file: http://bugs.python.org/file15175/MyCGIHTTPServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Thu Oct 22 12:40:40 2009
From: report at bugs.python.org (lekma)
Date: Thu, 22 Oct 2009 10:40:40 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1256208040.33.0.258211591456.issue3605@psf.upfronthosting.co.za>


Changes by lekma <lekmalek at gmail.com>:


----------
nosy: +lekma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu Oct 22 12:46:06 2009
From: report at bugs.python.org (Istvan Szirtes)
Date: Thu, 22 Oct 2009 10:46:06 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>


New submission from Istvan Szirtes <istvan.szirtes at gmail.com>:

The CSV module try to read a .csv file which is coded in utf-8 with utf-
8 BOM. 

The first row in the csv file is 
["value","vocal","vocal","vocal","vocal"]

in hex:
???"value","vocal","vocal","vocal","vocal"

the reader can not read corectly the first row and if I try to seek up 
to 0 somewhere in the file I got an error like this:

['\ufeff"value"', 'vocal', 'vocal', 'vocal', 'vocal']

I think the csv reader is not seekable correctly.

I attached a test file for the bug and here is my code:

import codecs
import csv

InDistancesFile = codecs.open( '..\\distances.csv', 'r', encoding='utf-
8' )
InDistancesObj = csv.reader( InDistancesFile )

for Row in InDistancesObj:
    if Row[0] == '20':
        print(Row)
        break

InDistancesFile.seek(0)

for Row in InDistancesObj:
    print(Row)

----------
components: Unicode
files: distances.csv
messages: 94340
nosy: W00D00
severity: normal
status: open
title: csv reader utf-8 BOM error
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15182/distances.csv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:03:54 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 22 Oct 2009 14:03:54 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256220234.37.0.236618488769.issue7185@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

http://docs.python.org/library/csv.html#module-csv states:

This version of the csv module doesn?t support Unicode input. Also,
there are currently some issues regarding ASCII NUL characters.
Accordingly, all input should be UTF-8 or printable ASCII to be safe;
see the examples in section Examples. These restrictions will be removed
in the future.

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:40:07 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 22 Oct 2009 14:40:07 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256222407.39.0.705226604376.issue7183@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Robert indicated later that this probably did /not/ affect Bazaar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:41:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Oct 2009 14:41:44 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256222504.33.0.120549681776.issue7183@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I added some tests in test_property in my checkout and the __doc__
property is not, as far as I can tell, set read-only by the issue 5890 fix.

The error message referenced in the report is:

AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__'
is read-only

If Boost.Python.StaticProperty is a subclass of Property, which seems
likely, then the 5890 fix could well be triggering this error, since if
a property created with a subclass is given a docstring, the fix creates
a __doc__ attribute in the subclass's dict.  If the subclass dict is
read only, the above error would be triggered.

I don't know enough about extension types to know if the property code
should be special casing extension types, but if it should, then IMO
that would qualify 5890 as a regression.  Otherwise I don't think it is,
though we could still consider whether making a change to reduce user
pain is worthwhile.  (To be worthwhile it would have to be likely to
reach the users before the Boost fix does...apparently Boos has a fix in
their SVN for this problem.)

I'm guessing that this is a problem only with extension types, not with
pure Python code.

----------
nosy: +r.david.murray
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:43:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Oct 2009 14:43:46 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256222626.72.0.0993469923219.issue7183@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That should have been 'instance's dict', not the subclass dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:51:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Oct 2009 14:51:16 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256223076.92.0.221428058604.issue7185@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The restrictions were theoretically removed in 3.1, and the 3.1
documentation has been updated to reflect that.  If 3.1 CSV doesn't
handle unicode, then that is a bug.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:53:54 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 22 Oct 2009 14:53:54 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256223234.27.0.130299427693.issue7185@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Then the solution should simply be to use "utf-8-sig" as the encoding,
instead of "utf-8".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:00:21 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:00:21 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1256223621.53.0.801615283566.issue6324@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75606.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:01:34 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 22 Oct 2009 15:01:34 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256223694.77.0.511346451306.issue7183@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks David, that's what I suspect too (that's its a problem with
extension types).  Unless we get more information, I'm not inclined to
hold up the 2.6.4 release for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:04:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:04:20 +0000
Subject: [issue7088] New (in 2.6) functions in signal module are not
	documented as unix-only
In-Reply-To: <1255058239.85.0.357925408849.issue7088@psf.upfronthosting.co.za>
Message-ID: <1256223860.33.0.344791734303.issue7088@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75607.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7088>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:10:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:10:49 +0000
Subject: [issue7067] Suggest better documentation of 2 versus 3 on 3.1.1 site.
In-Reply-To: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
Message-ID: <1256224249.8.0.206171886582.issue7067@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I added the 3.0 whatsnew and 2to3 links in (pydotorg) r12618.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7067>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:16:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:16:34 +0000
Subject: [issue7137] Socket documentation not updated
In-Reply-To: <1255577156.35.0.86012229105.issue7137@psf.upfronthosting.co.za>
Message-ID: <1256224594.32.0.0605286166497.issue7137@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75609.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7137>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:16:48 2009
From: report at bugs.python.org (Steven R. Loomis)
Date: Thu, 22 Oct 2009 15:16:48 +0000
Subject: [issue7067] Suggest better documentation of 2 versus 3 on 3.1.1 site.
In-Reply-To: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
Message-ID: <1256224608.71.0.429242627381.issue7067@psf.upfronthosting.co.za>


Steven R. Loomis <srl at monkey.sbay.org> added the comment:

Thnks for fixing this. there still seems to be something up with 
http://python.org/download/releases/3.1.1/  - it says 'Inline interpreted 
text or phrase reference start-string without end-string.' and the 
changelog link is broken. But I see the new links.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7067>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:18:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:18:47 +0000
Subject: [issue7062] No docs for module 'IN'
In-Reply-To: <1254723088.53.0.157607422381.issue7062@psf.upfronthosting.co.za>
Message-ID: <1256224727.49.0.0948646992579.issue7062@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's the case for all undocumented modules (there are some like IN,
that only contain constants; they're also going away in Py3k).  However,
pydoc can't know which modules are documented, so I'm going to close
this as "won't fix".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7062>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:27:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:27:43 +0000
Subject: [issue7036] Doc/reference/datamodel: Slots description needs update
In-Reply-To: <1254503745.39.0.693240836231.issue7036@psf.upfronthosting.co.za>
Message-ID: <1256225263.93.0.220826773166.issue7036@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

As far as I can tell, the text is still correct:

>>> class a(object): __slots__ = 'a'
>>> class b(a): __slots__ = 'a'

works without raising TypeError.

I've nevertheless enhanced the docs a bit in r75610.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7036>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:42:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:42:40 +0000
Subject: [issue7035] codecs error handlers lack documentation
In-Reply-To: <1254493113.5.0.852242878975.issue7035@psf.upfronthosting.co.za>
Message-ID: <1256226160.54.0.646344844253.issue7035@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75611.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7035>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:50:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Oct 2009 15:50:22 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256226622.56.0.625208458232.issue7183@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure I understand, how do you create a "read-only instance dict"?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:50:36 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:50:36 +0000
Subject: [issue7067] Suggest better documentation of 2 versus 3 on 3.1.1 site.
In-Reply-To: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
Message-ID: <1256226636.54.0.491007618177.issue7067@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, this is now fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7067>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:52:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:52:33 +0000
Subject: [issue7156] curses can't find _curses
In-Reply-To: <1255739388.85.0.756737488331.issue7156@psf.upfronthosting.co.za>
Message-ID: <1256226753.79.0.0478790116589.issue7156@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added "Platform: Unix" to curses docs in r75612.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7156>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:54:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 15:54:45 +0000
Subject: [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1256226885.05.0.549120048741.issue6977@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r75613.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:55:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Oct 2009 15:55:47 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256226947.92.0.747998851356.issue7183@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure you do.  I have no idea how Boost works, but the fact that
removing a Boost 'read-only' declaration circumvents the problem in at
least some cases argues that Boost is setting _something_ read-only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:06:55 2009
From: report at bugs.python.org (Steven R. Loomis)
Date: Thu, 22 Oct 2009 16:06:55 +0000
Subject: [issue7067] Suggest better documentation of 2 versus 3 on 3.1.1 site.
In-Reply-To: <1254775930.89.0.646782257739.issue7067@psf.upfronthosting.co.za>
Message-ID: <1256227615.03.0.607237534555.issue7067@psf.upfronthosting.co.za>


Steven R. Loomis <srl at monkey.sbay.org> added the comment:

welcome, looks great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7067>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:08:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 16:08:39 +0000
Subject: [issue6927] Metaclass doc (Ref 3.3.3) errors
In-Reply-To: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za>
Message-ID: <1256227719.56.0.57762143448.issue6927@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed based/passed in r75616, the rest will be done for #1294232.

----------
resolution:  -> fixed
status: open -> closed
superseder:  -> Error in metaclass search order

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6927>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:21:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 16:21:29 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1256228489.89.0.927267716019.issue6670@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, fixed in Sphinx, and in the Python stylesheet in r75617.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:26:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Oct 2009 16:26:19 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1256228779.71.0.0960607180135.issue7006@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

2to3 still uses hasattr(x, 'callable').

----------
assignee: georg.brandl -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:32:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Oct 2009 16:32:40 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256229160.38.0.67264472304.issue7185@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In that case we should update the docs.  Istvan, can you confirm that
this solves your problem?

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
stage: test needed -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:52:20 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 22 Oct 2009 16:52:20 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256230340.01.0.747763921252.issue1235@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Thu Oct 22 20:03:26 2009
From: report at bugs.python.org (Mark Sapiro)
Date: Thu, 22 Oct 2009 18:03:26 +0000
Subject: [issue5713] smtplib gets out of sync if server returns a 421 status
In-Reply-To: <1239049825.43.0.457403750239.issue5713@psf.upfronthosting.co.za>
Message-ID: <1256234606.43.0.752669836687.issue5713@psf.upfronthosting.co.za>


Mark Sapiro <mark at msapiro.net> added the comment:

I'm not completely sure about this, but here's my thoughts. In the
scenarios I've seen, the 421 reply/disconnect only occurs in response to
a RCPT which has an invalid address and follows several prior refused
RCPTs. In this case, I think the proper action is to close the
connection and raise SMTPRecipientsRefused and return a dictionary with
the actual responses for the refused RCPTS prior to the 421 and the 421
response only for the RCPT that produced it.

If the 421 comes at another time, I think the current process does the
right thing. It will raise the appropriate exception if it gets the
chance. It just needs to be sure that if the response was 421 that
instead of doing self.rset() it does self.close().

I have attached a patch against the 2.6.1 smtplib.py which I think does
the right thing. I haven't tested this at all, but I think it should
work. The documentation may need to be updated to emphasize that even
though all recipients aren't listed in the dictionary returned with the
SMTPRecipientsRefused exception, no one got the mail.

----------
keywords: +patch
Added file: http://bugs.python.org/file15183/smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5713>
_______________________________________

From report at bugs.python.org  Thu Oct 22 20:05:16 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 22 Oct 2009 18:05:16 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256234716.48.0.996837473426.issue7185@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu Oct 22 20:36:19 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 22 Oct 2009 18:36:19 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1256236579.27.0.437597168415.issue7183@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

After discussion on python-dev, this will not block 2.6.4

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Thu Oct 22 21:30:19 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 22 Oct 2009 19:30:19 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1256239819.7.0.148123280833.issue6952@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Updated patch with comment explaining cast.

----------
Added file: http://bugs.python.org/file15184/const_api_r75619.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Thu Oct 22 21:47:35 2009
From: report at bugs.python.org (steve steiner)
Date: Thu, 22 Oct 2009 19:47:35 +0000
Subject: [issue7186] Document specialness of __doc__,
	and possibly other "special" attributes
In-Reply-To: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>
Message-ID: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>


New submission from steve steiner <ssteiner at users.sourceforge.net>:

Around the time of the 2.6.4 release, it was suggested that Python 2.6.3
changed the __doc__ attribute to read-only.  See:
http://bugs.python.org/issue7183

When asked whether this read-only behaviour was intentional, Guido
answered, simply "Yes" and also wrote:

On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:

Well __doc__ isn't a normal attribute -- it doesn't follow inheritance
rules.

I suggested that it might be helpful to document this "special"
behaviour and also any other attributes that are "special" though which
ones they might be are unknown at this time.

----------
assignee: georg.brandl
components: Documentation
messages: 94369
nosy: georg.brandl, ssteiner
severity: normal
status: open
title: Document specialness of __doc__, and possibly other "special" attributes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7186>
_______________________________________

From report at bugs.python.org  Thu Oct 22 22:18:32 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 22 Oct 2009 20:18:32 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1256242712.95.0.101205418416.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Back ported the try/finally parts to trunk in r75620.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Thu Oct 22 22:37:07 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 22 Oct 2009 20:37:07 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode fails if it can't
	open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm working on an RPM package of Python 3.1.1 for Fedora [1].  Within my RPMs are 
precompiled .pyc and .pyo files that are not writable by users, and are hardlinked 
together if they have equal content.  For example:
$ ls -al /usr/lib/python3.1/tkinter/__init__.*
-rw-r--r--. 1 root root 157859 2009-10-22 15:43 
/usr/lib/python3.1/tkinter/__init__.py
-rw-r--r--. 2 root root 226817 2009-10-22 15:42 
/usr/lib/python3.1/tkinter/__init__.pyc
-rw-r--r--. 2 root root 226817 2009-10-22 15:42 
/usr/lib/python3.1/tkinter/__init__.pyo

I see numerous IOError permission errors running the regression test suite, with 
importlib/_bootstrap.py trying and failing to open the .pyc files for writing.  
The IOError bubbles up each time and causes the test to fail.

Here's a minimal reproducer (assuming such an install as above)
>>> from tkinter import Tcl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/importlib/_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "/usr/lib/python3.1/importlib/_bootstrap.py", line 399, in load_module
    return self._load_module(module)
  File "/usr/lib/python3.1/importlib/_bootstrap.py", line 324, in _load_module
    code_object = self.get_code(module.__name__)
  File "/usr/lib/python3.1/importlib/_bootstrap.py", line 443, in get_code
    self.write_bytecode(fullname, data)
  File "/usr/lib/python3.1/importlib/_bootstrap.py", line 171, in inner
    return method(self, name, *args, **kwargs)
  File "/usr/lib/python3.1/importlib/_bootstrap.py", line 525, in write_bytecode
    file = _io.FileIO(bytecode_path, 'w')  # Assuming bytes.
IOError: [Errno 13] Permission denied: '/usr/lib/python3.1/tkinter/__init__.pyc'

Upon investigating Lib/importlib/_bootstrap.py, the logic for handling permission 
errors in "write_bytecode" appears to be wrong:
  - the initializer for _io.FileIO can raise an "IOError" if it can't open the 
.pyc file for writing
    - see Modules/_io/fileio.c:fileio_init, the exception is indeed raised if the 
call to:
        self->fd = open(name, flags, 0666);
    fails.

So it looks like the try/except clause needs to be extended to also cover opening 
the file for writing, as well as writing the bytes to it.

I'm attaching a patch that makes this change.

With this change, the above failing import succeeds, and an invocation of 
/usr/lib/python3.1/test/regrtest.py improves from:
276 tests OK.
39 tests failed:
    test_cmd_line test_codeccallbacks test_codecencodings_cn
    test_codecencodings_hk test_codecencodings_jp
    test_codecencodings_kr test_codecencodings_tw test_cprofile
    test_distutils test_docxmlrpc test_email test_heapq
    test_htmlparser test_httpservers test_imp test_lib2to3
    test_linecache test_modulefinder test_multiprocessing test_osx_env
    test_plistlib test_pyclbr test_pydoc test_runpy test_socket
    test_sqlite test_sundry test_tcl test_threading_local test_tk
    test_ttk_guionly test_ttk_textonly test_uuid test_warnings
    test_wsgiref test_xml_etree_c test_xmlrpc test_xmlrpc_net
    test_zipfile
to:
304 tests OK.
10 tests failed:
    test_email test_httpservers test_imp test_lib2to3 test_linecache
    test_socket test_tk test_ttk_guionly test_ttk_textonly
    test_zipfile

(I'm working on these other failures; some of them are due to errors in my 
packaging)

FWIW the initial checkin of py3k/Lib/importlib/_bootstrap.py appears to have the 
initialization of the FileIO outside the try/except block:
http://svn.python.org/view/python/branches/py3k/Lib/importlib/_bootstrap.py?
view=markup&pathrev=68698

though at that time it was _fileio._FileIO, rather than _io.FileIO.  (did FileIO 
only test for perms upon writing, and change behavior to test upon opening?  or 
has this case always led to this failure?  or am I misreading this?)

Thanks
Dave

[1] https://bugzilla.redhat.com/show_bug.cgi?id=526126

----------
components: Library (Lib)
files: python-3.1.1-importlib-fix-handling-of-readonly-pyc-files.patch
keywords: patch
messages: 94371
nosy: dmalcolm
severity: normal
status: open
title: importlib/_bootstrap.py write_bytecode fails if it can't open the .pyc file for writing
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15185/python-3.1.1-importlib-fix-handling-of-readonly-pyc-files.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Thu Oct 22 22:43:31 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 22 Oct 2009 20:43:31 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256244211.42.0.262124463306.issue7187@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
title: importlib/_bootstrap.py write_bytecode fails if it can't open the .pyc file for writing -> importlib/_bootstrap.py write_bytecode raises an IOError if it can't open the .pyc file for writing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Fri Oct 23 00:14:05 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 22 Oct 2009 22:14:05 +0000
Subject: [issue7182] For non-debug builds,
	the cygwinccompiler.py should define NDEBUG
In-Reply-To: <1256147342.16.0.0286188762329.issue7182@psf.upfronthosting.co.za>
Message-ID: <1256249645.53.0.389833498807.issue7182@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Ok Daniel.
In this case for debug build _DEBUG has to be defined too - please check
pyconfig.h from MSVC builds.
May be you could use CFLAGS environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7182>
_______________________________________

From report at bugs.python.org  Fri Oct 23 02:02:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Oct 2009 00:02:49 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1256228779.71.0.0960607180135.issue7006@psf.upfronthosting.co.za>
Message-ID: <1afaf6160910221702g5c861bhc962baf2df3b365@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/10/22 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
> 2to3 still uses hasattr(x, 'callable')

Do you have strong opinions about this? IMO, hasattr(x, '__call__') is
compatible enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Oct 23 02:04:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Oct 2009 00:04:42 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256256282.7.0.0583673648954.issue7187@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:40:14 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2009 04:40:14 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256272812.05.0.572125254432.issue7187@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the report and potential fix, Dave. I'm swamped at the moment 
but I will get to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:41:20 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Oct 2009 04:41:20 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256272880.71.0.54771413225.issue7187@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Fri Oct 23 09:36:23 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Oct 2009 07:36:23 +0000
Subject: [issue7188] optionxform documentation confusing
In-Reply-To: <1256283382.97.0.071138181483.issue7188@psf.upfronthosting.co.za>
Message-ID: <1256283382.97.0.071138181483.issue7188@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

In
http://stackoverflow.com/questions/1611799/preserve-case-in-configparser, somebody
is confused about adjusting ConfigParser.optionxform. The documentation
is indeed confusing, in particular by claiming that you should "set" it
to "str()". Even if you get what is meant by "setting" (i.e. not
"calling"), it's still nonsensical to suggest that it should be set to
an empty string.

----------
assignee: georg.brandl
components: Documentation
messages: 94375
nosy: georg.brandl, loewis
severity: normal
status: open
title: optionxform documentation confusing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7188>
_______________________________________

From report at bugs.python.org  Fri Oct 23 09:37:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 23 Oct 2009 07:37:08 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is not
	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1256283428.61.0.366344443954.issue7006@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not really, that was the last thing to get this issue closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Oct 23 10:14:55 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 23 Oct 2009 08:14:55 +0000
Subject: [issue7188] optionxform documentation confusing
In-Reply-To: <1256283382.97.0.071138181483.issue7188@psf.upfronthosting.co.za>
Message-ID: <1256285695.59.0.106466212067.issue7188@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r75623.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7188>
_______________________________________

From report at bugs.python.org  Fri Oct 23 10:24:48 2009
From: report at bugs.python.org (brimac)
Date: Fri, 23 Oct 2009 08:24:48 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1256228489.89.0.927267716019.issue6670@psf.upfronthosting.co.za>
Message-ID: <9bd6f93d0910230124w1dfa3ea8od556d1f02ad5aff2@mail.gmail.com>


brimac <brimac at bcs.org> added the comment:

Georg, Ezio
Many Thanks
brimac

2009/10/22 Georg Brandl <report at bugs.python.org>

>
> Georg Brandl <georg at python.org> added the comment:
>
> OK, fixed in Sphinx, and in the Python stylesheet in r75617.
>
> ----------
> resolution:  -> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6670>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15186/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________
-------------- next part --------------
Georg, Ezio<br>Many Thanks<br>brimac<br><br><div class="gmail_quote">2009/10/22 Georg Brandl <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Georg Brandl &lt;<a href="mailto:georg at python.org">georg at python.org</a>&gt; added the comment:<br>
<br>
OK, fixed in Sphinx, and in the Python stylesheet in r75617.<br>
<br>
----------<br>
resolution: ??-&gt; fixed<br>
status: open -&gt; closed<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6670" target="_blank">http://bugs.python.org/issue6670</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Oct 23 12:24:28 2009
From: report at bugs.python.org (Igor Mikushkin)
Date: Fri, 23 Oct 2009 10:24:28 +0000
Subject: [issue7189] struct.calcsize returns strange size
In-Reply-To: <1256293468.22.0.147558321508.issue7189@psf.upfronthosting.co.za>
Message-ID: <1256293468.22.0.147558321508.issue7189@psf.upfronthosting.co.za>


New submission from Igor Mikushkin <igor.mikushkin at gmail.com>:

I think in second case struct size should be 53.

In [31]: struct.calcsize('ihhi35scc')
Out[31]: 49

In [32]: struct.calcsize('ihhi35scci')
Out[32]: 56

----------
components: Library (Lib)
messages: 94379
nosy: igor.mikushkin
severity: normal
status: open
title: struct.calcsize returns strange size
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7189>
_______________________________________

From report at bugs.python.org  Fri Oct 23 12:37:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 23 Oct 2009 10:37:09 +0000
Subject: [issue7189] struct.calcsize returns strange size
In-Reply-To: <1256293468.22.0.147558321508.issue7189@psf.upfronthosting.co.za>
Message-ID: <1256294229.76.0.479578451292.issue7189@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think the calcsize result is correct here.  With the native struct 
format, padding is included in the struct.

In the second case, there are three bytes of padding after the 'cc' and 
before the 'i'.  This keeps the 'i' aligned on a 4-byte boundary.  If you 
look at the results of struct.pack, you can see the padding explicitly:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('ihhi35scci', 123456789, 10000, 10000, 321456789, 
"abcdefghijklmnopqrstuvwxyz123456789", '+', '*', 231456789)
"\x15\xcd[\x07\x10'\x10'\x95\n)\x13abcdefghijklmnopqrstuvwxyz123456789+*\x
00\x00\x00\x15\xc0\xcb\r"

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7189>
_______________________________________

From report at bugs.python.org  Fri Oct 23 14:45:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 12:45:07 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256301907.29.0.89088747136.issue7187@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Wouldn't the problem disappear, though, if tkinter/__init__.py didn't
claim to be fresher than tkinter/__init__.pyc? Also, it would make the
pyc/pyo files actually useful, rather than having Python recompile the
source files again and again.
(see the modification dates in your listing)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Fri Oct 23 14:51:54 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 23 Oct 2009 12:51:54 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1256302314.14.0.695710106162.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Can we include this for the next release ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Fri Oct 23 14:57:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 12:57:01 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1256302621.17.0.901243036764.issue3488@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Fri Oct 23 14:57:50 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 23 Oct 2009 12:57:50 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1256302670.82.0.503194673348.issue6882@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Changed py3k version to use contextlib.closing in r75625.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Fri Oct 23 15:01:29 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 23 Oct 2009 13:01:29 +0000
Subject: [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1256302889.38.0.13559169344.issue6882@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________

From report at bugs.python.org  Fri Oct 23 15:06:02 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 23 Oct 2009 13:06:02 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1256303162.64.0.901618309016.issue7150@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

The issue is present in Python 3.0 and 2.5 as well.

Python 2.5.1 (r251:54863, Jul 17 2008, 13:21:31)
[GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t0=datetime.datetime(1,1,1)
>>> d1,d2,d3=map(datetime.timedelta, range(1,4))
>>> t0-d1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range
>>> t0-d2
datetime.datetime(1, 0, 255, 0, 0)

I think this is bug in datetime for all Python versions

----------
nosy: +pythonhacker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Fri Oct 23 15:25:36 2009
From: report at bugs.python.org (Justin)
Date: Fri, 23 Oct 2009 13:25:36 +0000
Subject: [issue7190] TCP/IP?
In-Reply-To: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
Message-ID: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>


New submission from Justin <shmee8000 at yahoo.com>:

Mac OS X
IBook G4 PowerPC

when running target.py it works fine until i close the app without
ending the process. (before 'q' is entered by the user). sometimes
python will not allow the user to click in the window and have the
ability to type after running the target window. sometimes the mouse
clicks affect a part of IDLE up and left of where the actual click was.
when i ignore this error (this is the only thing i have open in IDLE) i
must fist close out of python and reopen target.py i have used this
approach to test and find that there are no bugs in my program (at least
it works above and beyond the specifications of my class assignment),
but every once in while i will get an error when trying to use 'q' to
end the program and python will state that win.getMouse() is not a
viable term to use, because (win) is already closed yet when 'q' is used
the if statement has the close command right underneath the get mouse
command.
*note* i have coded another program specifically from John Zelle's
"Python Programming: An Introduction to Computer Science" p.160
programming exercise #1 and my get display text, get mouse, then close
window is verbatim from that in target.py and it never showed an error
in the #1's program

IDLE can't bind TCP/IP port 8833, which is necessary to communicate with
its Python execution server. Either no networking is installed on this
computer or another process (another IDLE?) is using the port. Run IDLE
with the -n command line switch to start without a subprocess and refer
to Help/IDLE Help 'Running without a subprocess' for further details.

----------
assignee: ronaldoussoren
components: Macintosh
files: target.py
messages: 94385
nosy: jlr2383, ronaldoussoren
severity: normal
status: open
title: TCP/IP?
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15187/target.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7190>
_______________________________________

From report at bugs.python.org  Fri Oct 23 15:40:57 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 23 Oct 2009 13:40:57 +0000
Subject: [issue7191] Odd behaviour with zlib.decompressobj optional parameter
	"wbits"
In-Reply-To: <1256305257.34.0.885450394278.issue7191@psf.upfronthosting.co.za>
Message-ID: <1256305257.34.0.885450394278.issue7191@psf.upfronthosting.co.za>


New submission from Anand B Pillai <abpillai at gmail.com>:

>>> import zlib
>>> help(zlib.decompressobj)
Help on built-in function decompressobj in module zlib:

decompressobj(...)
    decompressobj([wbits]) -- Return a decompressor object.

    Optional arg wbits is the window buffer size.

I experimented with this parameter and by trial and
error found out that it accepts only values from 8 to
15 inclusive. 

>>> z=zlib.decompressobj(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid initialization option

>>> z1=zlib.decompressobj(8)
>>> z2=zlib.decompressobj(15)

Now to the odd part. Let us create another decompressobj without any
parameter. 

>>> z3=zlib.decompressobj()

Now compress some data.
>>> c=zlib.compress("This is a medium line of text")

Decompress with z2 works fine.
>>> z3.decompress(c)
b'This is a medium line of text'

Decompress with z2 is also fine.

>>> z2.decompress(c)
b'This is a medium line of text'

However with z1 it fails.
>>> z1.decompress(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
zlib.error: Error -3 while decompressing: invalid window size

In fact, only the optional value of 15 seems to work 
for wbits, every other legal value (8-14) fails giving
the same error. I tried this with other random strings
with same effect.

Either there is no need to expose this as a parameter
or there could be a bug with how this parameter is used,
which has to be fixed. In either case, documentation
on this parameter has to be improved and legal range
of values should be provided.

----------
components: Library (Lib)
messages: 94386
nosy: pythonhacker
severity: normal
status: open
title: Odd behaviour with zlib.decompressobj optional parameter "wbits"
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7191>
_______________________________________

From report at bugs.python.org  Fri Oct 23 16:07:37 2009
From: report at bugs.python.org (Andrew Dalke)
Date: Fri, 23 Oct 2009 14:07:37 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

I have Firefox and Safari installed on my Mac. Safari is the default.

I wanted to try out Crunchy (http://code.google.com/p/crunchy/). It's 
developed under Firefox and does not work under Safari. I tried. ;)

It starts the web browser with the following.

    try:
        client = webbrowser.get("firefox")
        client.open(url)
        return
    except:
        try:
            client = webbrowser.get()
            client.open(url)
            return
        except:
            print('Please open %s in Firefox.' % url)

On my Mac, webbrowser.get("firefox") fails, so this ends up opening in 
Safari. Which does not work to view the code.

Thing is, I have Firefox installed, so it should work. But the Mac code in 
webbrowser appears to only open in the default browser.

The following bit of code works well enough to get crunchy to work

    class MacOSXFirefox(BaseBrowser):
        def open(self, url, new=0, autoraise=True):
            subprocess.check_call(["/usr/bin/open", "-b", 
"org.mozilla.firefox", url])

    register("firefox", None, MacOSXFirefox('firefox'), -1)

but I don't know enough about the Mac nor about webbrowser to know if I'm 
the right path. For example, I don't know if there are ways to support 
'new' and 'autoraise' through /usr/bin/open or if there's a better 
solution.

Attached is the full diff.

----------
components: Library (Lib)
files: webbrowser.py.diff
keywords: patch
messages: 94387
nosy: dalke
severity: normal
status: open
title: webbrowser.get("firefox") does not work on Mac with installed Firefox
type: feature request
Added file: http://bugs.python.org/file15188/webbrowser.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Fri Oct 23 17:24:09 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 23 Oct 2009 15:24:09 +0000
Subject: [issue7187] importlib/_bootstrap.py write_bytecode raises an IOError
	if it can't open the .pyc file for writing
In-Reply-To: <1256243827.37.0.0884595993995.issue7187@psf.upfronthosting.co.za>
Message-ID: <1256311449.6.0.764849557538.issue7187@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Aha!  Thanks pitrou, looks like I managed to mess up my packaging (I was
wondering why no no-one else had run into this, looks like no-one else
made this mistake!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7187>
_______________________________________

From report at bugs.python.org  Fri Oct 23 17:47:38 2009
From: report at bugs.python.org (Dan Griffin)
Date: Fri, 23 Oct 2009 15:47:38 +0000
Subject: [issue7193] Popen blocks program from another thread
In-Reply-To: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>
Message-ID: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>


New submission from Dan Griffin <dgriff1 at gmail.com>:

When I create a thread that does a Popen it blocks the entire program. I
have attached a simple sample program. Whether I do Popen.wait or
Popen.poll the program blocks. I have done this on OSX 10.5 and 10.6. I
have not yet tried ussing the multiprocessing module.

----------
components: Library (Lib)
files: subproc.py
messages: 94389
nosy: dgriff1
severity: normal
status: open
title: Popen blocks program from another thread
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15189/subproc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7193>
_______________________________________

From report at bugs.python.org  Fri Oct 23 19:09:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Oct 2009 17:09:45 +0000
Subject: [issue7193] Popen blocks program from another thread
In-Reply-To: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>
Message-ID: <1256317785.03.0.0363434419387.issue7193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are calling the 'run' method of your test class, which runs the
subprocess in the main thread.  Try calling t.start() instead.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7193>
_______________________________________

From report at bugs.python.org  Fri Oct 23 19:11:32 2009
From: report at bugs.python.org (Dan Griffin)
Date: Fri, 23 Oct 2009 17:11:32 +0000
Subject: [issue7193] Popen blocks program from another thread
In-Reply-To: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>
Message-ID: <1256317892.47.0.929163172156.issue7193@psf.upfronthosting.co.za>


Dan Griffin <dgriff1 at gmail.com> added the comment:

You are right, sorry to waste your time.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7193>
_______________________________________

From report at bugs.python.org  Fri Oct 23 19:12:01 2009
From: report at bugs.python.org (Dan Griffin)
Date: Fri, 23 Oct 2009 17:12:01 +0000
Subject: [issue7193] Popen blocks program from another thread
In-Reply-To: <1256312858.52.0.307226158644.issue7193@psf.upfronthosting.co.za>
Message-ID: <1256317921.78.0.657311492845.issue7193@psf.upfronthosting.co.za>


Changes by Dan Griffin <dgriff1 at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7193>
_______________________________________

From report at bugs.python.org  Fri Oct 23 20:20:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 18:20:47 +0000
Subject: [issue7194] test_thread is flaky
In-Reply-To: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>
Message-ID: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_thread sometimes tries to release an unacquired mutex. It is easier
to reproduce when using the "-j" option (on trunk and py3k, since the
option doesn't exist on 2.6/3.1):

./python -m test.regrtest -j4 test_thread test_thread test_thread
test_thread
test_thread
test_thread
test_thread
Unhandled exception in thread started by <bound method
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests
testMethod=test_stack_size>>
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_thread.py", line 49, in
task
    self.done_mutex.release()
_thread.error: release unlocked lock
test_thread

----------
components: Library (Lib), Tests
messages: 94392
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_thread is flaky
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7194>
_______________________________________

From report at bugs.python.org  Fri Oct 23 20:36:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 18:36:05 +0000
Subject: [issue7194] test_thread is flaky
In-Reply-To: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>
Message-ID: <1256322965.02.0.795058839743.issue7194@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in trunk, py3k and 3.1. Waiting for 2.6 to unfreeze before merging
there.

----------
assignee:  -> pitrou
resolution:  -> accepted
stage: needs patch -> committed/rejected
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7194>
_______________________________________

From report at bugs.python.org  Fri Oct 23 23:39:23 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Oct 2009 21:39:23 +0000
Subject: [issue7195] Value error 'path is on drive c: start on drive d:' in
	os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

A simple test fails:

Python 2.6.3 (r263rc1:75186, Oct 2, 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)] on win32
>>> import os
>>> os.path.relpath('\\bar', 'd:\\')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python\lib\ntpath.py", line 487, in relpath
    % (path_list[0], start_list[0]))
ValueError: path is on drive C:, start on drive d:

If I change the current directory to 'E:\', the error changes to "path
is on drive E:, start on drive d:".

Clearly, relpath is doing some calculations based on the current
directory, although the documentation states that it should be
performing a relative path calculation based on the supplied start
("D:\" in this case).

In Python 3.1.1, the error is "path is on mount 'C:', start on mount 'd:'"

os.path.relpath should be able to perform relative path calculations
regardless of the current directory, or the documentation should explain
why the current directory is relevant when start is supplied.

----------
components: Windows
messages: 94394
nosy: jaraco
severity: normal
status: open
title: Value error 'path is on drive c: start on drive d:' in os.path.relpath
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7195>
_______________________________________

From report at bugs.python.org  Sat Oct 24 00:08:29 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Oct 2009 22:08:29 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256335709.5.0.623925954933.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After some in-depth analysis, I determined the following:

1) The new symlink-aware os.stat has to find the target of a symlink to
properly function.
2) The previously-proposed patch uses GetFilenameByHandle in os.stat to
find the target, but this fails when a handle can't be obtained (such as
when a symlink points to pagefile.sys.
3) Explorer doesn't use GetFilenameByHandle. I used ProcMon to monitor
the API calls when it looks up the properties for a symlink to
pagefile.sys. It appears to use CreateFile and DeviceIoControl to trace
through the symlink chain.

So, I've written a proof of concept that determines a symlink target
using these API calls. The code is in jaraco.windows.filesystem at
https://svn.jaraco.com/jaraco/python/jaraco.windows/jaraco/windows/filesystem.py:trace_symlink_target
.  For convenience, I've pasted the most relevant code segments at
http://paste.turbogears.org/paste/122986 .

I'd like to get comments on this implementation before porting this to
the C code and adding it to the os.stat call. One of the aspects that
makes me uncomfortable is the fact that I have to call relpath between
each iteration.

I have tested this approach fairly thoroughly. It appears to work under
all circumstances (through multiple symlinks across drives and
ultimately pointing at pagefile.sys).

If no one can suggest a better approach, I plan to code this into the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Oct 24 00:22:20 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2009 22:22:20 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1256336540.31.0.679749393331.issue6986@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pitrou> Unit tests are definitely desireable!

done

pitou> I would also like the "alternate approach" fix, 
pitou> it would probably be cleaner.

done. See the new patch.

----------
Added file: http://bugs.python.org/file15190/json-crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Sat Oct 24 00:37:39 2009
From: report at bugs.python.org (Tracy Poff)
Date: Fri, 23 Oct 2009 22:37:39 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256337459.83.0.517265906708.issue1087418@psf.upfronthosting.co.za>


Changes by Tracy Poff <tracy.poff at gmail.com>:


----------
nosy: +sopoforic

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 01:31:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 23:31:08 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1256340668.12.0.768944882139.issue6986@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There is actually a Lib/json/tests/ directory contain all JSON tests,
you should add yours there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Sat Oct 24 01:34:02 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2009 23:34:02 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1256340842.93.0.0119092180559.issue6986@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pitrou> There is actually a Lib/json/tests/ directory contain all 
pitrou> JSON tests, you should add yours there.

My patch creates the file Lib/json/tests/test__json.py. Do you mean
that I should add the new tests to an existing file? Which one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Sat Oct 24 01:38:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Oct 2009 23:38:15 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1256341095.66.0.0761707901816.issue6986@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, my bad, I thought it created the file in Lib/test.
The tests probably need to be skipped if _json can't be imported, though.
(the _json accelerators are just an implementation detail)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Sat Oct 24 03:56:10 2009
From: report at bugs.python.org (Gregory Smith)
Date: Sat, 24 Oct 2009 01:56:10 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256349370.93.0.165380742655.issue1087418@psf.upfronthosting.co.za>


Gregory Smith <gregsmith at users.sourceforge.net> added the comment:

Actually, my view for 3.x is this: I do agree hugely with the 'top
level' decision to only have one type that handles everything, and
obviously the easiest way to get there is to just use the existing long
type. However, though the rad-2^15 implementation of the 'long' type was
a fine thing for the 2.x python where it's only used for relatively
unusual cases, I think it's too inefficient to use as the primary
integer type, so I'm wondering if there's a plan to replace it with
something more efficient (thus rendering this particular issue irrelevant).

I did spend some time delving into python internals years ago, but
haven't really looked into 3.x, so bear with me. I am aware of the
following 'speed tweaks' in Python 2.x integers, aren't these lost now?

   (1) integers all same size, allocated from linked-list pool instead
of from malloc
   (2) 'add' and 'sub' byte codes do special check in interpreter core
to see if ints being added, and will go direct to PyInt_FromLong where
possible

It would seem to me that a more suitable implementation would be to
store numbers as 32*k-bit 2's complement integers; I've used this in C++
libraries. Compared to the rad-15 sign/magnitude approach, it may seem
trickier to do carries but in practice it's not that big a deal. It also
basically assumes you have a decently fast 64-bit operation to do
multiplies and divides with, which I think is now reasonable. This
implementation will be much easier to optimize for the (now) extremely
common case where numbers fit into 32 bits.
It could also be possible to store 'wee' integers in a special pool and
only use malloc for larger ones. 

I know there's a lot of code in that module, virtually all of which
would be affected by this. But isn't this type now a big performance
factor in 3.x?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 06:33:45 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Oct 2009 04:33:45 +0000
Subject: [issue7196] Clarify str.split() behavior
In-Reply-To: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>
Message-ID: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Clarify str.split() behavior; see discussion at http://
comments.gmane.org/gmane.comp.python.general/641120

----------
assignee: georg.brandl
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 94401
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: Clarify str.split() behavior
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15191/stdtypes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7196>
_______________________________________

From report at bugs.python.org  Sat Oct 24 08:05:19 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 24 Oct 2009 06:05:19 +0000
Subject: [issue7196] Clarify str.split() behavior
In-Reply-To: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>
Message-ID: <1256364319.37.0.867960988463.issue7196@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7196>
_______________________________________

From report at bugs.python.org  Sat Oct 24 08:50:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 06:50:15 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256367015.65.0.234608532096.issue1087418@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The type is an important performance factor but most uses of it are for
small ints (< 2**32 or 2**64), so your approach wouldn't make much of a
difference.
Besides, there are already some improvements in the py3k branch (for
example, longs now use 30-bit "digits" on 64-bit systems).

> I am aware of the
> following 'speed tweaks' in Python 2.x integers, aren't these lost now?

Yes, they are. As a result, calculations on small ints have become a bit
slower.

----------
nosy: +pitrou
versions: +Python 3.2 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 10:13:55 2009
From: report at bugs.python.org (Istvan Szirtes)
Date: Sat, 24 Oct 2009 08:13:55 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1256372035.62.0.270190586827.issue7185@psf.upfronthosting.co.za>


Istvan Szirtes <istvan.szirtes at gmail.com> added the comment:

Hi Everyone,

I have tried the "utf-8-sig" and it does not work in this case or 
rather I think not the csv module is wrong. The seek() does not work 
correctly in the csv file or object.

With "utf-8-sig" the file is opend correctly and the first row does not 
include the BOM problem. It is great. 
I am sorry I have not known this until now. (I am not a python expert 
yet :))

However, I have gote some misstake like this 'AFTE\ufeffVALUE".WAV' 
during my running script.

"AFTER" is a valid string in the given csv file but the BOM follows it.
This happens after when I seek up to "0" some times in the csv file.
And the string "afte?value" LEAVE_HIGHWAY-E" is produced which is wrong.

My sollution is that I convert the csv object into a list after the 
file openeing:

        InDistancesFile = codecs.open( Root, 'r', encoding='utf-8' )
        txt = InDistancesFile.read()[1:] # to leave the BOM
        lines = txt.splitlines()[1:] # to leave the first row which is 
a header
        InDistancesObj = list(csv.reader( lines )) # convert the csv 
reader object into a simple list

Many thanks for your help,
Istvan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Sat Oct 24 11:10:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 09:10:16 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256375416.32.0.740300080578.issue1087418@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Greg]
> It would seem to me that a more suitable implementation would be to
> store numbers as 32*k-bit 2's complement integers; I've used this in 
> C++ libraries. Compared to the rad-15 sign/magnitude approach, it may
> seem trickier to do carries but in practice it's not that big a deal.

Do you know of any publicly available code that takes this approach, 
while remaining simple and portable?

For 32-bit limbs (on a 32-bit platform, say, with no C99 support and no 
uint64_t available), how *do* you deal with carries?  You can write 
portable C89 that does the correct thing, but you then have to cross 
your fingers and hope that the compiler can turn it into sensible 
assembler, and it often can't (I'll post an example of this that I ran 
into just yesterday in a second).  And even if your compiler can 
optimize this effectively, what about all the other compilers out there?  
The alternative is to use inline assembler for selected platforms;  at 
that point, you lose simplicity.

The sign-magnitude versus two's complement is an orthogonal issue, I 
think.  I'm not convinced of the value of two's complement.  Certainly 
two's complement would be more convenient for the bitwise operations 
under discussion, and probably also works well for addition and 
subtraction.  But it's less convenient for negation, multiplication, 
division, power, conversion to and from human-readable strings, etc.  
It's worth noting that GMP uses sign-magnitude, so I can't believe there 
could be much performance gain in moving to two's complement.  
(Actually, I'm not sure I've seen any arbitrary-precision arithmetic 
package that uses two's complement.  Has anyone here?)

Here's the example promised earlier:  yesterday I wanted to add two 128-
bit unsigned integers a and b, each represented as a pair of type 
uint64_t integers, on a 64-bit machine.  In portable C99, the code looks 
something like:

#include <stdint.h>

/* *sumhigh:*sumlow = ahigh:alow + bhigh:blow */

void
add_128(uint64_t *sumhigh, uint64_t *sumlow,
           uint64_t ahigh, uint64_t alow,
           uint64_t bhigh, uint64_t blow)
{
  alow += blow;
  ahigh += bhigh + (alow < blow);
  *sumlow = alow;
  *sumhigh = ahigh;
}

Ideally, the compiler would manage to optimize this to a simple 'addq, 
adcq' pair of instructions.  But gcc-4.4 -O3, on OS X 10.6/x86_64 gives 
me:

_add_128:
LFB0:
        leaq    (%r9,%rcx), %rcx
        xorl    %eax, %eax
        leaq    (%r8,%rdx), %rdx
        pushq   %rbp
LCFI0:
        cmpq    %r9, %rcx
        movq    %rcx, (%rsi)
        setb    %al
        movq    %rsp, %rbp
LCFI1:
        addq    %rax, %rdx
        movq    %rdx, (%rdi)
        leave
        ret

(Here it looks like alow and blow are in r9 and rcx, ahigh and bhigh are 
in r8 and rdx, and rsi and rdi are sumlow and sumhigh.)

How do you write the C code in such a way that gcc produces the right 
result?  I eventually gave up and just put the assembler in directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 11:23:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 09:23:15 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256376195.38.0.79577326477.issue1087418@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the inline assembly version, for comparison:

#define SUM2_BIN64(sumhigh, sumlow, ahigh, alow, bhigh, blow)    \
  __asm__ ("addq\t%5, %1\n\t"                                    \
           "adcq\t%3, %0"                                        \
           : "=r" (sumhigh), "=&r" (sumlow)                      \
           : "0" ((uint64_t)(ahigh)), "rm" ((uint64_t)(bhigh)),  \
             "%1" ((uint64_t)(alow)), "rm" ((uint64_t)(blow))    \
           : "cc")

void
add_128_asm(uint64_t *sumhigh, uint64_t *sumlow,
           uint64_t ahigh, uint64_t alow,
           uint64_t bhigh, uint64_t blow)
{
  SUM2_BIN64(ahigh, alow, ahigh, alow, bhigh, blow);
  *sumlow = alow;
  *sumhigh = ahigh;
}

And the generated output (again gcc-4.4 with -O3):

_add_128_asm:
LFB1:
        pushq   %rbp
LCFI2:
# 29 "test.c" 1
        addq    %r9, %rcx
        adcq    %r8, %rdx
# 0 "" 2
        movq    %rsp, %rbp
LCFI3:
        movq    %rcx, (%rsi)
        movq    %rdx, (%rdi)
        leave
        ret

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:13:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 11:13:45 +0000
Subject: [issue7197] test_multiprocessing crashes under Windows when run in
	verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

When run under Windows in verbose mode ("python -m test.regrtest -v
test_multiprocessing"), most tests in test_multiprocessing fail with a
recursion limit error.

The explanation is that most tests are written in the following manner:

class _TestArray(BaseTestCase):
    [...]
    def test_array(self, raw=False):
        [...]
        p = self.Process(target=self.f, args=(arr,))

Running a Process under Windows involved pickling it to send it to the
child process. This also pickles the `target` function, which here is a
method of an unittest instance. This consequently pickles the unittest
instance, which has a reference to the unittest runner, which has a
reference to a unittest.runner._WritelnDecorator instance.

The infinite recursion occurs when unpickling the _WritelnDecorator
instance, because the `stream` attribute is not restored when calling
__new__, and the __getattr__ method then recurses when trying to return
`getattr(self.stream,attr)`.

I see two possible resolutions:
- make unittest.runner._WritelnDecorator properly (un)pickleable 
- change all tests in test_multiprocessing to avoid pickling instances
of unittest.TestCase

The former is simpler and probably more future-proof than the latter.

(NB: in non-verbose mode, test.support uses a custom test runner which
doesn't involve the _WritelnDecorator)


Appendix: here is a traceback example (noticed on the newgil branch but
it really happens on stock trunk and py3k):

test_notify (test.test_multiprocessing.WithProcessesTestCondition) ...
Traceback
 (most recent call last):
  File "<string>", line 1, in <module>
  File "Z:\py3k\newgil\lib\multiprocessing\forking.py", line 339, in main
    self = load(from_parent)
  File "Z:\py3k\newgil\lib\pickle.py", line 1365, in load
    encoding=encoding, errors=errors).load()
  File "Z:\py3k\newgil\lib\unittest\runner.py", line 21, in __getattr__
    return getattr(self.stream,attr)
  File "Z:\py3k\newgil\lib\unittest\runner.py", line 21, in __getattr__
    return getattr(self.stream,attr)
  File "Z:\py3k\newgil\lib\unittest\runner.py", line 21, in __getattr__
    return getattr(self.stream,attr)
[... snipped ...]
RuntimeError: maximum recursion depth exceeded while calling a Python
object

----------
components: Library (Lib), Tests
messages: 94406
nosy: jnoller, michael.foord, pitrou
priority: high
severity: normal
status: open
title: test_multiprocessing crashes under Windows when run in verbose mode
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7197>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:33:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 11:33:16 +0000
Subject: [issue7197] test_multiprocessing crashes under Windows when run in
	verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1256383996.96.0.636620295991.issue7197@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amusingly, there is a Test_TextTestRunner but it's not run by
test_unittest....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7197>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:49:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 11:49:16 +0000
Subject: [issue7197] test_multiprocessing crashes under Windows when run in
	verbose mode
In-Reply-To: <1256382825.55.0.179199170316.issue7197@psf.upfronthosting.co.za>
Message-ID: <1256384956.54.0.25656928739.issue7197@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file15192/testrunner.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7197>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:51:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Oct 2009 11:51:07 +0000
Subject: [issue7191] Odd behaviour with zlib.decompressobj optional parameter
	"wbits"
In-Reply-To: <1256305257.34.0.885450394278.issue7191@psf.upfronthosting.co.za>
Message-ID: <1256385067.27.0.696687936984.issue7191@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The decompressor can't have a window size smaller than the size used to
compress the stream.  Therefore in your case, it can't be smaller than 15.

Still, the docs must be improved, e.g. compressobj() has more parameters
than documented.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7191>
_______________________________________

From report at bugs.python.org  Sat Oct 24 14:21:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 12:21:45 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1256386905.22.0.782395517028.issue6242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I just noticed that this hadn't been committed to trunk. I did the
backport myself, but in the future please first commit IO changes to
trunk and then merge to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6242>
_______________________________________

From report at bugs.python.org  Sat Oct 24 14:55:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 12:55:48 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1256388948.06.0.552190236399.issue3578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it's probably a duplicate of #7105.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> weak dict iterators are fragile because of unpredictable GC runs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Sat Oct 24 14:56:44 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 24 Oct 2009 12:56:44 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256389004.69.0.605824329718.issue7175@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The subversion system looks pretty nice !

So here's a modified proposal that covers the python version as well.

= per user configuration files = 

 ~/.pythonMAJOR.MINOR

Examples:

~/.python2.7
~/.python3.1

On Windows, ~ will be replaced by APPDATA if founded in the environment.
 
== global configuration files ==


On Linux/Mac:

/etc/pythonMAJOR.MINOR

examples:

/etc/python2.7/
/etc/python3.1/

On Windows:

\All users\Application Data\PythonMAJORMINOR

(\All users\Application Data is specified by the Windows Registry)

examples:

\All users\Application Data\Python26
\All users\Application Data\Python31

== standard naming for configuration files ==

The files are all named "NAME.cfg", in all platforms.

== what gets in per-user configuration directory ==

- pypi.cfg
- distutils.cfg

== what gets in global configuration directory ==

- distutils.cfg

== apis added ==

in site.py:

- getuserconfig() : returns the per-user configuration directory
- getconfig(): returns the global configuration directory

(the names are following site.py naming style)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Sat Oct 24 14:59:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 12:59:51 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
	hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1256389191.28.0.849630741696.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Kristj?n:
> So, can one just clear the __traceback__ member?

Yes, or use `exc_value.with_traceback(None)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7060>
_______________________________________

From report at bugs.python.org  Sat Oct 24 15:41:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 13:41:05 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256391665.8.0.874616034785.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some key revision numbers from the py3k short float repr, for reference:

r71663:  include Gay's code, build and configure fixes
r71723:  backout SSE2 detection code added in r71663
r71665:  rewrite of float formatting code to use Gay's code

Backported most of r71663 and r71723 to trunk in:

r75651: Add dtoa.c, dtoa.h, update license.
r75658: configuration changes - detect float endianness,
        add functions to get and set x87 control word, and
        determine when short float repr can be used.

Significant changes from r71663 not yet included:

* Misc/NEWS update
* Lib/test/formatfloat_testcases.txt needs updating to match py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 24 15:45:33 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 24 Oct 2009 13:45:33 +0000
Subject: [issue7066] archive_util.make_archive doesn't restore the cwd if an
	error is raised
In-Reply-To: <1254771627.9.0.528035502085.issue7066@psf.upfronthosting.co.za>
Message-ID: <1256391933.72.0.459190988662.issue7066@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Done in r75659, r75662 and r75663 (merge in 2.6 maint. waiting for 2.6.4
final tag to be done)

Thanks !

----------
status: open -> closed
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7066>
_______________________________________

From report at bugs.python.org  Sat Oct 24 16:05:28 2009
From: report at bugs.python.org (Gregory Smith)
Date: Sat, 24 Oct 2009 14:05:28 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256393128.99.0.821080774081.issue1087418@psf.upfronthosting.co.za>


Gregory Smith <gregsmith at users.sourceforge.net> added the comment:

Antoine, "most uses of it are for small ints (< 2**32 or 2**64), ",
that's my point exactly, the current long type is quite slow for those
cases because of sign-magnitude implementation.

I don't see a problem with sign-magnitude for old long ints, or for GMP,
since in those cases the assumption is that you have a fair percentage
of large #s, this is not valid in Py3.0 where most are small. Most
operations are add and subtract, and in each such operation you need to
look at both signs, and decide if you want to really add or subtract,
and if you are subtracting, you then have to do a magnitude test to see
which way - all of that before you do any actual computation. That's a
lot of overhead for e.g. 'i -= 1'. Especially given that the sign &
length information are rolled together into a single value; you need a
fair number of tests & conditional branches. With a 2's complement
implementation you would test for the most common case where both values
are 1 digit (which would include 0 value) and in that case do an add (or
subtract) followed by a check for overflow, and that's the whole thing.
I'm guessing this is 10% - 25% as much time as in the current
implementation - this is one of those cases where the time for tests and
setup dominate over the actual computation.

Mark, what you've written looks fine to me. It would be a bit faster
with an add-with-carry, but there's no conditional branches in the
generated code, so it's not bad, it's still faster than it would be if
you were extracting carries from the msb of each result and masking them
afterwards. Bear in mind that some RISC processors don't have an
add-with-carry (lacking condition codes altogether) so the method of
comparing the sum to the inputs is the only method available. Given that
in Python the operation is in a loop, I think it's unreasonable to to
expect a compiler to identify an add-with-carry application, but at the
same time it's not necessary. Now that the long int is the *only* int
type, multi-digit ops will be relatively uncommon, and you want to focus
on reducing the overhead before and after the operation.

(And, for speed freaks who want to use long ints to implement large bits
arrays and want fast bit ops - my original motivation for this issue -
it would be possible to use SSE2 vector instructions on specific
processors. That can also be done with the 15-bit implementation, but it
works much better with 32).


The 'algorithmic C' package
(http://www.mentor.com/products/esl/high_level_synthesis/ac_datatypes)
is a C++ template class for arbitrary-length signed/unsigned integers.
It's not suitable for use in Python because of license issues and
because its integers are controlled by templates and are fixed-size at
compile time - but it uses Kx32-bit 2's complement format, and
implements adds, shifts, multiplies, logic ops, and limited division
ops. It works very well, with extremely low overhead on small values -
often the code is exactly the same as if you used int type  - that would
not be possible with a sign/magnitude approach.

As for multiplies and divides - it's certainly possible to proceed
through a multiply entirely in 2's complement, so no overhead is needed
for abs value, or changing sign at the end. For division, it's possible
if the denominator is > 0, and it may be possible if <0 (but probably
not worth the hassle).

I would be happy to do a design doc for this and write some of the inner
loops, but if (a) it's already being done or (b) there's no chance of it
being deployed then it would be a waste of time...
if there was definite interest in it (and reasonable schedule
expectations) I could write a lot more of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 16:06:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 14:06:28 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256393188.98.0.391719530828.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r75666: Add sys.float_repr_style attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 24 16:13:16 2009
From: report at bugs.python.org (Mancausoft)
Date: Sat, 24 Oct 2009 14:13:16 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1256393596.7.0.974948702192.issue1678380@psf.upfronthosting.co.za>


Mancausoft <bug at mancausoft.org> added the comment:

This bug is still present on arm. 

Python 2.6.3 

cs-e9302# cat ../prova.py
import  math
print math.atan2(0., -0.)
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)

cs-e9302# cat ../prova1.py
import  math
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)

cs-e9302# ./python ../prova1.py
(-4.0, -4.0)
-3.14159265359
(-4.0, -4.0)
-3.14159265359
cs-e9302# ./python ../prova.py
0.0
(4.0, -4.0)
0.0
(4.0, -4.0)
0.0




>>> from math import atan2
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359
>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y,
-1.)")
-3.14159265359
>>> x = -0.; atan2(0., -1)
-3.1415926535897931
>>> x = 0.; atan2(0., -1)
3.1415926535897931

======================================================================
FAIL: testAtan2 (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 131, in testAtan2
    self.ftest('atan2(0., -0.)', math.atan2(0., -0.), math.pi)
  File "Lib/test/test_math.py", line 57, in ftest
    (name, value, expected))
AssertionError: atan2(0., -0.) returned 0.0, expected
3.1415926535897931

======================================================================
FAIL: testCopysign (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 806, in testCopysign
    self.assertEqual(math.copysign(4., -0.), -4.0)
AssertionError: 4.0 != -4.0

----------------------------------------------------------------------

----------
nosy: +mancausoft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 16:19:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 14:19:34 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1256393974.85.0.304963767914.issue1678380@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Mancausoft:  is this little-endian, OABI?

If so, then I think I know  what the problem is:  the disambiguation code 
in compile.c looks at the first and last bytes of the double to 
distinguish 0.0 and -0.0;  for mixed-endian (aka little-endian, swapped 
words) doubles this will fail.

The solution is to use copysign instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 16:25:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 24 Oct 2009 14:25:50 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
In-Reply-To: <1256393128.99.0.821080774081.issue1087418@psf.upfronthosting.co.za>
Message-ID: <4AE30E6B.6090503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would be happy to do a design doc for this and write some of the inner
> loops, but if (a) it's already being done or (b) there's no chance of it
> being deployed then it would be a waste of time...
> if there was definite interest in it (and reasonable schedule
> expectations) I could write a lot more of it.

I think the only realistic chance in which something may change is that
somebody sits down and does all the work, from beginning to end. I doubt
that a design doc and some inner loops alone will make any difference.

It's not being done (to my knowledge), for the reason alone that it
would be a lot of work. It has a chance to be deployed only if a)
it is significantly faster, for small numbers, b) correct, and c)
only slightly more complicated than the current code.

I notice that such discussion is off-topic for this bug report, which
is about your original patch. All we have to decide here is whether to
accept it (perhaps with modifications), or to reject it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 16:41:10 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 24 Oct 2009 14:41:10 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1256395270.04.0.310895237399.issue7071@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Notice that install_lib has a --no-compile option that can be used to
avoid compiling .pyc/.pyo files.

What I am adding now is just a gentle warning in case a compilation is
tried and sys.dont_write_bytecode is True, so the installation may
proceed nevertheless and it doesn't through an error.

For the 2.6 backport, it can be added in 2.6.5 I guess,

----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:14:08 2009
From: report at bugs.python.org (Mancausoft)
Date: Sat, 24 Oct 2009 15:14:08 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
In-Reply-To: <1256393974.85.0.304963767914.issue1678380@psf.upfronthosting.co.za>
Message-ID: <20091024171433.7acf1ff9@homer>


Mancausoft <bug at mancausoft.org> added the comment:

Mark Dickinson <report at bugs.python.org> scrisse:

> Mancausoft:  is this little-endian, OABI?

Mixed endian

> If so, then I think I know  what the problem is:  the disambiguation
> code in compile.c looks at the first and last bytes of the double to 
> distinguish 0.0 and -0.0;  for mixed-endian (aka little-endian,
> swapped words) doubles this will fail.
> 
> The solution is to use copysign instead.

I try: *p==0 && p[sizeof(double)-1]==0 && p[(sizeof(double)-1)/2]==0;

and now the test_math result is:

Ran 39 tests in 21.323s

OK        

It's a safe patch?

Mancausoft

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:21:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 15:21:42 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1256397702.31.0.67920123032.issue1678380@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I try: *p==0 && p[sizeof(double)-1]==0 && p[(sizeof(double)-1)/2]==0;

Sure, that should work.  It would seem cleaner and safer to use copysign, 
though: that way, things will still work when some other byte layout comes 
along, or when some version of Python starts using 128-bit IEEE 754 
doubles instead of 64-bit, or ...

Reopening:  I've been meaning to fix these checks to use copysign for a 
while now, anyway.

----------
priority: high -> normal
resolution: accepted -> 
stage:  -> needs patch
status: closed -> open
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:28:18 2009
From: report at bugs.python.org (Matteo Bertini)
Date: Sat, 24 Oct 2009 15:28:18 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1256398098.41.0.891963876269.issue7111@psf.upfronthosting.co.za>


Changes by Matteo Bertini <matteob at naufraghi.net>:


----------
nosy: +naufraghi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:28:47 2009
From: report at bugs.python.org (Matteo Bertini)
Date: Sat, 24 Oct 2009 15:28:47 +0000
Subject: [issue7111] stdout closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1256398127.46.0.840547403731.issue7111@psf.upfronthosting.co.za>


Changes by Matteo Bertini <matteob at naufraghi.net>:


----------
title: core dump when stderr is moved -> stdout closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:29:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 15:29:31 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1256398171.37.0.369315153923.issue1678380@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for floats.  Mancausoft, could you give this a try and let 
me know whether it fixes the issue?

The same fix would also need to be applied for complex numbers.

----------
Added file: http://bugs.python.org/file15193/issue1678380.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:30:14 2009
From: report at bugs.python.org (Matteo Bertini)
Date: Sat, 24 Oct 2009 15:30:14 +0000
Subject: [issue7111] core dump when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1256398214.73.0.333741574127.issue7111@psf.upfronthosting.co.za>


Matteo Bertini <matteob at naufraghi.net> added the comment:

sorry, title restored!

----------
title: stdout closed -> core dump when stderr is moved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:45:25 2009
From: report at bugs.python.org (Mancausoft)
Date: Sat, 24 Oct 2009 15:45:25 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
In-Reply-To: <1256398171.37.0.369315153923.issue1678380@psf.upfronthosting.co.za>
Message-ID: <20091024174524.2134d2cb@homer>


Mancausoft <bug at mancausoft.org> added the comment:

Mark Dickinson <report at bugs.python.org> scrisse:

> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Here's a patch for floats.  Mancausoft, could you give this a try and
> let me know whether it fixes the issue?

it works.

test_math

Ran 39 tests in 23.561s                                               

OK

test_float
Ran 19 tests in 275.241s

OK

Mancausoft

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 18:02:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 16:02:09 +0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1256400129.26.0.0286288030743.issue1678380@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for testing!  I'll apply the fix once the 2.6 branch is unfrozen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_______________________________________

From report at bugs.python.org  Sat Oct 24 18:02:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 16:02:52 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256400172.16.0.893352286348.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r75672:  temporarily disable the short float repr while we're putting
         the pieces in place.

When testing, the disablement can be disabled (hah) by defining the 
PY_SHORT_FLOAT_REPR preprocessor symbol, e.g. (on Unix) with

CC='gcc -DPY_SHORT_FLOAT_REPR' ./configure && make

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 24 18:10:58 2009
From: report at bugs.python.org (Matteo Bertini)
Date: Sat, 24 Oct 2009 16:10:58 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1256400658.88.0.573057043476.issue1488934@psf.upfronthosting.co.za>


Changes by Matteo Bertini <matteob at naufraghi.net>:


----------
nosy: +naufraghi
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Sat Oct 24 18:19:20 2009
From: report at bugs.python.org (Matteo Bertini)
Date: Sat, 24 Oct 2009 16:19:20 +0000
Subject: [issue1596] Broken pipes should be handled better in 2.x
In-Reply-To: <1197410546.31.0.23440598734.issue1596@psf.upfronthosting.co.za>
Message-ID: <1256401160.86.0.932573014635.issue1596@psf.upfronthosting.co.za>


Changes by Matteo Bertini <matteob at naufraghi.net>:


----------
nosy: +naufraghi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596>
_______________________________________

From report at bugs.python.org  Sat Oct 24 18:27:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 16:27:39 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1256401659.65.0.903266605616.issue6986@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The tests could go in Lib/json/tests/test_speedups.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Sat Oct 24 19:04:41 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 24 Oct 2009 17:04:41 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256403881.05.0.986120622858.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think the next step on my side is to remove _PyOS_double_to_string,
and make all of the internal code call PyOS_double_to_string. The
distinction is that _PyOS_double_to_string gets passed a buffer and
length, but  PyOS_double_to_string returns allocated memory that must be
freed. David Gay's code (_Py_dg_dtoa) returns allocated memory, so
that's the easiest interface to propagate internally.

That's the approach we used in the py3k branch. I'll start work on it.
So Mark's work should be mostly config stuff and hooking up Gay's code
to PyOS_double_to_string. I think it will basically match the py3k version.

The existing _PyOS_double_to_string will become the basis for the
fallback code for use when PY_NO_SHORT_FLOAT_REPR is defined (and it
will then be renamed PyOS_double_to_string and have its signature
changed to match).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 24 20:15:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 18:15:42 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256408142.96.0.789250104902.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One issue occurs to me: should the backport change the behaviour of the 
round function?

In py3k, round consistently uses round-half-to-even for halfway cases.
In trunk, round semi-consistently uses round-half-away-from-zero (and 
this is documented).  E.g., round(1.25, 1) will give 1.2 in py3k and 
(usually) 1.3 in trunk.

I definitely want to use Gay's code for round in 2.7, since having round 
work sensibly is part of the motivation for the backport in the first 
place.  But this naturally leads to a round-half-to-even version of 
round, since the Python-adapted version of Gay's code isn't capable of 
doing anything other than round-half-to-even at the moment.

Options:

(1) change round in 2.7 to do round-half-to-even.  This is easy,
    natural, and means that round will agree with float formatting
    (which does round-half-to-even in both py3k and trunk).  But it
    may break existing applications.  However:  (a) those applications
    would need fixing anyway to work with py3k, and (b) I have little
    sympathy for people depending on behaviour of rounding of
    *binary* floats for halfway *decimal* cases.  (Decimal is another
    matter, of course:  there it's perfectly reasonable to expect
    guaranteed rounding behaviour.)

    It's more complicated than that, though, since if rounding
    becomes round-half-to-even for floats, it should also change
    for integers, Fractions, etc.

(2) have round stick with round-half-away-from-zero.  This may be
    awkward to implement (though I have some half-formed ideas about
    how to make it work), and would lead to round occasionally not
    agreeing with float formatting.  For example:

    >>> '{0:.1f}'.format(1.25)
    '1.2'
    >>> round(1.25, 1)
    1.3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 24 20:21:32 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 24 Oct 2009 18:21:32 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1256408492.96.0.261640303749.issue3488@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Seems simple enough, I don't see why not.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Sat Oct 24 20:29:45 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 24 Oct 2009 18:29:45 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256408985.08.0.750292347821.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Adding tim_one as nosy. He'll no doubt have an opinion on rounding. And
hopefully he'll share it!

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 24 20:44:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 18:44:20 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1256409860.53.0.080081439536.issue1625@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not comfortable with the following change (which appears twice in
the patch):

-			BZ2_bzReadClose(&bzerror, self->fp);
+			if (self->fp)
+				BZ2_bzReadClose(&bzerror, self->fp);
 			break;
 		case MODE_WRITE:
-			BZ2_bzWriteClose(&bzerror, self->fp,
-					 0, NULL, NULL);
+			if (self->fp)
+				BZ2_bzWriteClose(&bzerror, self->fp,
+						 0, NULL, NULL);


If you need to test for the file pointer, perhaps there's a logic flaw
in your patch. Also, it might be dangerous in write mode: could it occur
that the file isn't closed but the problem isn't reported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sat Oct 24 21:25:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Oct 2009 19:25:42 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256412342.43.0.0207027571859.issue1087418@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Most operations are add and subtract, and in each such operation you
> need to look at both signs, and decide if you want to really add or
> subtract, and if you are subtracting, you then have to do a magnitude
> test to see which way - all of that before you do any actual
> computation. That's a lot of overhead for e.g. 'i -= 1'.

Hmm.  I agree this isn't ideal, and I now see the attraction of
two's complement.  Thanks.

It would be interesting to see timings from such an approach.
Maybe one could just implement the basic operations (+, -, *, /)
to get an idea of whether it's worth considering more seriously.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sat Oct 24 21:29:56 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Sat, 24 Oct 2009 19:29:56 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1256412596.31.0.430411121873.issue2504@psf.upfronthosting.co.za>


Changes by Andrew Ziem <ahz001 at gmail.com>:


----------
nosy: +AndrewZiem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sat Oct 24 22:02:49 2009
From: report at bugs.python.org (Tom Lynn)
Date: Sat, 24 Oct 2009 20:02:49 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1256414569.78.0.493311625079.issue2746@psf.upfronthosting.co.za>


Changes by Tom Lynn <tlynn at users.sourceforge.net>:


----------
nosy: +tlynn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2746>
_______________________________________

From report at bugs.python.org  Sat Oct 24 22:53:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Oct 2009 20:53:58 +0000
Subject: [issue7111] abort when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1256417638.66.0.844003215338.issue7111@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
title: core dump when stderr is moved -> abort when stderr is moved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sat Oct 24 23:17:24 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 24 Oct 2009 21:17:24 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256419044.41.0.253067042556.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Another thing to consider is that in py3k we removed all conversions of
converting 'f' to 'g', such as this, from Objects/unicodeobject.c:

    if (type == 'f' && fabs(x) >= 1e50)
        type = 'g';

Should we also do that as part of this exercise? Or should it be another
issue, or not done at all?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sun Oct 25 00:07:04 2009
From: report at bugs.python.org (Bob Cannon)
Date: Sat, 24 Oct 2009 22:07:04 +0000
Subject: [issue7198] csv.writer
Message-ID: <1256422023.94.0.440310821765.issue7198@psf.upfronthosting.co.za>


Changes by Bob Cannon <bob at neqn.net>:


----------
nosy: zacktu
severity: normal
status: open
title: csv.writer
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Sun Oct 25 00:08:41 2009
From: report at bugs.python.org (Bob Cannon)
Date: Sat, 24 Oct 2009 22:08:41 +0000
Subject: [issue7198] csv.writer
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>


New submission from Bob Cannon <bob at neqn.net>:

I used csv.writer to open a file for writing with comma as separator and
dialect='excel'.  I used writerow to write each row into the file.  When
I execute under linux, each line is terminated by '\r\n'.  When I
execute under windows, each line is terminated by '\r\r\n'.  Thus, under
MS Windows, when I read the csv file, there is a blank line between each
significant line.  I have dropped cvs.writer and now build each line
manually and terminate it with '\n'.  When the line is written in
windows, it is terminated by '\r\n'.  That's what should happen.  

As I see it, writerow with dialect='excel' should only terminate a line
with '\n'.  Windows will automatically place a '\r' in front of the '\n'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Sun Oct 25 00:52:32 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 24 Oct 2009 22:52:32 +0000
Subject: [issue7198] csv.writer
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1256424752.59.0.0399724912441.issue7198@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Your output file should be opened in binary mode.  Sounds like you
opened it in text mode.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Sun Oct 25 00:58:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2009 22:58:51 +0000
Subject: [issue7199] Doc: Logging level order seems inconsistent
In-Reply-To: <1256425131.73.0.619062754292.issue7199@psf.upfronthosting.co.za>
Message-ID: <1256425131.73.0.619062754292.issue7199@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

LibRef 15.6, Logging module:
<Assigned to Vinay because I understand you to be the current maintainer
of logging. If wrong, please reassign.>

Intro start with "The default levels provided are DEBUG, INFO, WARNING,
ERROR and CRITICAL." which seems like the proper ordering. Then

15.6.1.1. Simple examples
"Another useful feature of the logging API is the ability to produce
different messages at different log levels. This allows you to
instrument your code with debug messages, for example, but turning the
log level down so that those debug messages are not written for your
production system. The default levels are CRITICAL, ERROR, WARNING,
INFO, DEBUG and NOTSET.

The logger, handler, and log message call each specify a level. The log
message is only emitted if the handler and logger are configured to emit
messages of that level or lower. "

Ie, the order is reversed and the level specified is the highest level
emitted, which struck me as backwards, versus

15.6.1.2. Loggers
"Logger.setLevel() specifies the lowest-severity log message a logger
will handle, where debug is the lowest built-in severity level and
critical is the highest built-in severity. "

so that it emits the that level or *higher*.
(although notset is the actual lowest built-in.)

Reading further, I see that the builtin levels range for NOTSET=0 to
CRITICAL=50 (15.6.2. Logging Levels), so I think the first quote should
be changed to

"Another useful feature of the logging API is the ability to produce
different messages at different log levels. This allows you to
instrument your code with debug messages, for example, but turning the
log level up so that those debug messages are not written for your
production system. The default levels are NOTSET, DEBUG, INFO, WARNING,
ERROR, and CRITICAL.

The logger, handler, and log message call each specify a level. The log
message is only emitted if the handler and logger are configured to emit
messages of that level or higher. "

I have not checked the rest of the doc for other backwards passages.

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 94439
nosy: tjreedy, vinay.sajip
severity: normal
status: open
title: Doc: Logging level order seems inconsistent
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7199>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:10:37 2009
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 24 Oct 2009 23:10:37 +0000
Subject: [issue7200] multiprocessing deadlock on Mac OS X when queue collected
	before process terminates
In-Reply-To: <1256425837.07.0.628633816678.issue7200@psf.upfronthosting.co.za>
Message-ID: <1256425837.07.0.628633816678.issue7200@psf.upfronthosting.co.za>


New submission from Brian Quinlan <brian at sweetapp.com>:

This code:

import multiprocessing
import queue

def _process_worker(q):
    while True:
        try:
            something = q.get(block=True, timeout=0.1)
        except queue.Empty:
            return
        else:
            pass
            # print('Grabbed item from queue:', something)


def _make_some_processes(q):
    processes = []
    for _ in range(10):
        p = multiprocessing.Process(target=_process_worker, args=(q,))
        p.start()
        processes.append(p)
    return processes

#p = []
def _do(i):
    print('Run:', i)
    q = multiprocessing.Queue()
#    p.append(q)
    print('Created queue')
    for j in range(30):
        q.put(i*30+j)
    processes = _make_some_processes(q)
    print('Created processes')

    while not q.empty():
        pass
    print('Q is empty')

for i in range(100):
    _do(i)

Produces this output on Mac OS X (it produces the expected output on
Linux and Windows):

Run: 0
Created queue
Grabbed item from queue: 0
...
Grabbed item from queue: 29
Created processes
Q is empty
Run: 1
Created queue
Grabbed item from queue: 30
...
Grabbed item from queue: 59
Created processes
Q is empty
Run: 2
Created queue
Created processes
<no further output>

Changing the code as follows:

+ p = []
def _do(i):
    print('Run:', i)
    q = multiprocessing.Queue()
+   p.append(q)
    print('Created queue')
    for j in range(30):
        q.put(i*30+j)
    processes = _make_some_processes(q)
    print('Created processes')

    while not q.empty():
        pass
    print('Q is empty')

fixes the deadlock. So it looks like if a multiprocessing.Queue is
collected with sub-processes still using it then calling some methods on
other multiprocessing.Queues with deadlock.

----------
components: Library (Lib)
messages: 94440
nosy: bquinlan
severity: normal
status: open
title: multiprocessing deadlock on Mac OS X when queue collected before process terminates
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7200>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:10:42 2009
From: report at bugs.python.org (Bob Cannon)
Date: Sat, 24 Oct 2009 23:10:42 +0000
Subject: [issue7198] csv.writer
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1256425842.2.0.281854428737.issue7198@psf.upfronthosting.co.za>


Bob Cannon <bob at neqn.net> added the comment:

Probably so.  I'm sorry to report this as a bug if it's not.  I asked
abut this on a Python group on IRC and got no suggestions.  Thanks for
taking a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:11:18 2009
From: report at bugs.python.org (Bob Cannon)
Date: Sat, 24 Oct 2009 23:11:18 +0000
Subject: [issue7198] csv.writer
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1256425878.79.0.771519387216.issue7198@psf.upfronthosting.co.za>


Changes by Bob Cannon <bob at neqn.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:37:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 23:37:56 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1256427476.29.0.631246736063.issue2746@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you include the cElementTree fix and test case in your patch as well?

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2746>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:40:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Oct 2009 23:40:21 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1256427621.1.0.239442453361.issue2746@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, sorry, I hadn't read your message about the patch also correcting
cElementTree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2746>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:52:40 2009
From: report at bugs.python.org (Mancausoft)
Date: Sat, 24 Oct 2009 23:52:40 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>


New submission from Mancausoft <bug at mancausoft.org>:

I compile python for arm (on debian etch) but it don't  pass ctype
test:

======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
----------------------------------------------------------------------                    
Traceback (most recent call last):                                                        
  File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H
    self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))                                                     
AssertionError: (99, 88) != (198, 264)                                                                     

======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
----------------------------------------------------------------------            
Traceback (most recent call last):                                                
  File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H
    self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))                                                     
AssertionError: (99, 88) != (198, 264)                                                                     

======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.BasicWrapTestCase)
----------------------------------------------------------------------       
Traceback (most recent call last):                                           
  File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H
    self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (99, 88) != (198, 264)

======================================================================
FAIL: test_endian_double (ctypes.test.test_byteswap.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_byteswap.py",
line 137, in test_endian_double
    self.failUnlessEqual(bin(struct.pack("<d", math.pi)), bin(s))
AssertionError: '182D4454FB210940' != 'FB210940182D4454'

======================================================================
FAIL: test_unaligned_native_struct_fields
(ctypes.test.test_byteswap.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_byteswap.py",
line 277, in test_unaligned_native_struct_fields
    self.failUnlessEqual(bin(s1), bin(s2))
AssertionError: '123412007856341200B81E09401F85EB51' !=
'1234120078563412001F85EB51B81E0940'

----------
assignee: theller
components: ctypes
messages: 94444
nosy: mancausoft, theller
severity: normal
status: open
title: double Endian problem and more on arm
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7201>
_______________________________________

From report at bugs.python.org  Sun Oct 25 02:06:50 2009
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 25 Oct 2009 00:06:50 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1256429210.6.0.873324059766.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

With Python 3.1.1, the following batch file seems to be necessary to use
UTF-8 successfully from an XP console:

set PYTHONIOENCODING=UTF-8
cmd /u /k chcp 65001
set PYTHONIOENCODING=
exit

the cmd line seems to be necessary because of Windows having
compatibility issues, but it seems that Python should notice the cp65001
and not need the PYTHONIOENCODING stuff.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Oct 25 04:37:09 2009
From: report at bugs.python.org (David Bonner)
Date: Sun, 25 Oct 2009 03:37:09 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1256441829.21.0.642723106535.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

That was mostly just out of paranoia, since the comments mentioned 
multiple calls to close being legal.  Looking at it again, that particular 
case isn't an issue, since we don't hit that call when the mode is 
MODE_CLOSED.  The testsuite runs happily with those changes reverted.  
Should I upload a new patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sun Oct 25 06:56:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Oct 2009 05:56:21 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256450181.6.0.860148290495.issue7117@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 on backporting the 'f' and 'g' work also.
We will be well served by getting the two
code bases ins-sync with one another.

Eliminating obscure differences makes it easier
to port code from 2.x to 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sun Oct 25 09:11:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Oct 2009 08:11:34 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1256458294.32.0.582711531877.issue7201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The 4th failure (test_endian_double) probably has nothing to do with 
ctypes.  See also issue #1762561.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7201>
_______________________________________

From report at bugs.python.org  Sun Oct 25 10:29:53 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 25 Oct 2009 09:29:53 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1256462993.08.0.123568087978.issue7150@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

The problem seems to be in the "normalize_date" function in
datetimemodule.c. It is checking for a valid year range, but not
checking for a valid month or day range. 

I have a patch which fixes this problem. It checks for month range
(1<=m<=12) and day range(1<=d<=31). Here is Python with the patch.

anand at anand-laptop:~/projects/python/py3k$ ./python
Python 3.2a0 (py3k:75627, Oct 25 2009, 14:28:21) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "/home/anand/.pythonrc", line 2, in <module>
    import readline
ImportError: No module named readline
>>> import datetime
>>> t0=datetime.datetime(1,1,1)
>>> d1,d2,d3=map(datetime.timedelta, range(1,4))
>>> t0-d1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range
>>> t0-d2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range
>>> t0-d3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range
>>> d0=datetime.timedelta(0)
>>> t0-d0
datetime.datetime(1, 1, 1, 0, 0)
>>> 

Svn diff is attached.

----------
Added file: http://bugs.python.org/file15194/datetimemodule.c.svndiff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Sun Oct 25 13:40:32 2009
From: report at bugs.python.org (Mancausoft)
Date: Sun, 25 Oct 2009 12:40:32 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256458294.32.0.582711531877.issue7201@psf.upfronthosting.co.za>
Message-ID: <20091025134024.6412ad10@homer>


Mancausoft <bug at mancausoft.org> added the comment:

Mark Dickinson <report at bugs.python.org> scrisse:

> The 4th failure (test_endian_double) probably has nothing to do with 
> ctypes.  See also issue #1762561.

I try to use the patch arm-float2.diff, but test result is the same: 

======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last): File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y),
(99*2, 88*3)) AssertionError: (99, 88) != (198,
264)                                                                     

======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last): File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y),
(99*2, 88*3)) AssertionError: (99, 88) != (198,
264)                                                                     

======================================================================
FAIL: test_struct_return_2H
(ctypes.test.test_as_parameter.BasicWrapTestCase)
----------------------------------------------------------------------
Traceback (most recent call last): File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_as_parameter.py", line
171, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y),
(99*2, 88*3)) AssertionError: (99, 88) != (198, 264)

======================================================================
FAIL: test_endian_double (ctypes.test.test_byteswap.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_byteswap.py",
line 137, in test_endian_double
self.failUnlessEqual(bin(struct.pack("<d", math.pi)), bin(s))
AssertionError: '182D4454FB210940' != 'FB210940182D4454'

======================================================================
FAIL: test_unaligned_native_struct_fields
(ctypes.test.test_byteswap.Test)
----------------------------------------------------------------------
Traceback (most recent call last): File
"/mnt/root/stackless-2.6.3/Lib/ctypes/test/test_byteswap.py", line 277,
in test_unaligned_native_struct_fields self.failUnlessEqual(bin(s1),
bin(s2)) AssertionError: '123412007856341200B81E09401F85EB51' !=
'1234120078563412001F85EB51B81E0940'

----------------------------------------------------------------------
Ran 324 tests in 8.525s

Mancausoft

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7201>
_______________________________________

From report at bugs.python.org  Sun Oct 25 14:29:19 2009
From: report at bugs.python.org (Galen Clark Haynes)
Date: Sun, 25 Oct 2009 13:29:19 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1256477359.84.0.507531185646.issue6729@psf.upfronthosting.co.za>


Changes by Galen Clark Haynes <gchaynes at gmail.com>:


----------
nosy: +robotify

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Sun Oct 25 15:00:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Oct 2009 14:00:41 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256479241.64.0.37011150726.issue1087418@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think Greg's patch looks fine, modulo updating it to apply cleanly to 
py3k.

I couldn't resist tinkering a bit, though:  factoring out the complement 
operations (for a, b and z) into a separate function gives (IMO) cleaner 
and more direct code that's free of mask operations.

Here's the patch.

----------
Added file: http://bugs.python.org/file15195/long_bitwise_ops_metd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sun Oct 25 15:34:42 2009
From: report at bugs.python.org (Domen)
Date: Sun, 25 Oct 2009 14:34:42 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1256481282.18.0.604399646426.issue2054@psf.upfronthosting.co.za>


Domen <ielectric at gmail.com> added the comment:

What about AUTH SSL? Or is it too-deprecated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Sun Oct 25 15:37:09 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sun, 25 Oct 2009 14:37:09 +0000
Subject: [issue7202] "python setup.py MYCOMMAND --verbose" does not yield an
	unrecognized option error but also does not set the verbosity
In-Reply-To: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
Message-ID: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

This command:

python setup.py --verbose darcsver

works as expected -- the presence of '--verbose' increases the verbosity
of logging.

This command:

python setup.py darcsver --verbose

does not increase the verbosity, nor does it tell me that the
"--verbose" option is an option unknown to the "darcsver" command.

This command:

python setup.py darcsver --quux

gives this helpful output:

usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or:
setup.py cmd --help

error: option --quux not recognized

I think that the middle command ("python setup.py darcsver --verbose")
ought to behave either like the first command by increasing the
verbosity, or like the last command by telling the user that "--verbose"
is not a known option in that position.

This is also http://bitbucket.org/tarek/distribute/issue/78/

----------
assignee: tarek
components: Distutils
messages: 94453
nosy: tarek, zooko
severity: normal
status: open
title: "python setup.py MYCOMMAND --verbose" does not yield an unrecognized option error but also does not set the verbosity

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7202>
_______________________________________

From report at bugs.python.org  Sun Oct 25 16:02:47 2009
From: report at bugs.python.org (Derk Drukker)
Date: Sun, 25 Oct 2009 15:02:47 +0000
Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows
	if sys.executable contains blanks
In-Reply-To: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>
Message-ID: <1256482967.76.0.920637471818.issue1235@psf.upfronthosting.co.za>


Derk Drukker <derk.drukker at gmail.com> added the comment:

More elegant than using quotes in the cmdline string is, IMO, passing a
sequence to subprocess.Popen instead.  I've put a new patch up for
review: http://codereview.appspot.com/141050

I've also unified the Unix and Windows portions in run_cgi.  Both now
use subprocess.  (Which on Unix still calls fork and exec, as before.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1235>
_______________________________________

From report at bugs.python.org  Sun Oct 25 18:53:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Oct 2009 17:53:26 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Currently, ``map(None, a)`` is recognized and converted to ``list(a)``
which is correct but quite useless.

``map(None, a, b, ...)`` is not treated specially.  An approximate
translation would be ``map(lambda *xs: xs, a, b, ...)`` which however
doesn't take into account that the new map cuts after the shortest
sequence instead of "filling up" the shorter ones with Nones.

That should probably produce a warning.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 94455
nosy: georg.brandl
priority: high
severity: normal
stage: needs patch
status: open
title: fixer for map(None, ...) needs to consider multi-argument case
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Sun Oct 25 19:19:01 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sun, 25 Oct 2009 18:19:01 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256494741.96.0.682968342513.issue7203@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


----------
nosy: +segfaulthunter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Sun Oct 25 19:23:10 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sun, 25 Oct 2009 18:23:10 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256494990.28.0.27164227445.issue7203@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

A full fix would be

list(map(fun, *zip(*itertools.zip_longest(a, b, ...))))

and if fun is None

list(map(lambda *xs: xs, *zip(*itertools.zip_longest(a, b, ...))))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Sun Oct 25 19:29:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 25 Oct 2009 18:29:21 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256495361.19.0.394817207477.issue1087418@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Mark, if you want to get reviews, it might be useful to upload the patch
to Rietveld (as the diff is difficult to read). However, I would trust
you to get it right, anyway, so feel free to go ahead and apply it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:01:49 2009
From: report at bugs.python.org (Thomas Klausner)
Date: Sun, 25 Oct 2009 20:01:49 +0000
Subject: [issue7204] Strange shebang line in test_pep263
In-Reply-To: <1256500909.23.0.301695923413.issue7204@psf.upfronthosting.co.za>
Message-ID: <1256500909.23.0.301695923413.issue7204@psf.upfronthosting.co.za>


New submission from Thomas Klausner <tk at giga.or.at>:

In Python-2.6.3, test_pep263.py starts with the following line:
#! -*- coding: koi8-r -*-
When this is executed by a shell, it looks for the interpreter "-*-".
I guess the '!' is superfluous there, or it should be something like
#! /usr/bin/env python
# -*- coding: koi8-r -*-
instead.

----------
components: Tests
messages: 94458
nosy: wiz
severity: normal
status: open
title: Strange shebang line in test_pep263
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7204>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:12:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Oct 2009 20:12:35 +0000
Subject: [issue7204] Strange shebang line in test_pep263
In-Reply-To: <1256500909.23.0.301695923413.issue7204@psf.upfronthosting.co.za>
Message-ID: <1256501555.98.0.0643920824559.issue7204@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This has already been fixed in r69619.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7204>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:23:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Oct 2009 20:23:01 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1256502181.15.0.57585319568.issue7201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Okay, I take it back then. :)  Sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7201>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:46:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Oct 2009 20:46:07 +0000
Subject: [issue1087418] long int bitwise ops speedup (patch included)
Message-ID: <1256503567.38.0.702198786405.issue1087418@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r75697 (trunk) and r75698 (py3k).

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087418>
_______________________________________

From report at bugs.python.org  Sun Oct 25 22:55:54 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 25 Oct 2009 21:55:54 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

There is a systemic bug in BZ2File where the GIL is released to perform
compression work, and any other thread calling into BZ2File will
deadlock. We noticed in the write method, but inspection of the code
makes it clear that its systemic.

The problem is pretty simple. Say you have two threads and one bz2file
object. One calls write(), the other calls (say) seek(), but it could be
write() or other methods too. Now, its pretty clear that the question
'should these two threads get serialised' could be contentious. So lets
put that aside by saying 'raising an exception or serialising in
arbitrary order would be ok'.

What happens today is:
t1:bz2file.write
   bz2file.lock.acquire
   gil-release
   bz2compression starts
t2:gil-acquired
   bz2file.seek
   bz2file.lock.acquire(wait=1)  <- this thread is stuck now, and has
the GIL
t1:bz2compression finishes
   gil.acquire <- this thread is stuck now, waiting for the GIL

If any owner of the bz2file object lock will release the GIL, *all*
routines that attempt to lock the bz2file object have to release the GIL
if they can't get the lock - blocking won't work. I'm not familiar
enough with the python threading API to know whether its safe to call
without the GIL. If its not then clearly it can't be used to work with
getting the GIL, and lower layer locks should be used.

----------
components: Extension Modules
files: bz2fail.py
messages: 94462
nosy: barry, rbcollins, statik
severity: normal
status: open
title: bz2file deadlock
type: crash
Added file: http://bugs.python.org/file15196/bz2fail.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Sun Oct 25 23:00:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Oct 2009 22:00:23 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256508023.0.0.772966425634.issue7205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, nice catch.

----------
nosy: +pitrou
priority:  -> high
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Sun Oct 25 23:15:05 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 25 Oct 2009 22:15:05 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256508023.0.0.772966425634.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256508896.14292.85.camel@lifeless-64>


Robert Collins <robertc at robertcollins.net> added the comment:

On Sun, 2009-10-25 at 22:00 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Thanks, nice catch.

Yeah :).

> versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

Python 2.5 is also affected - its what we're running on the server that
broke :) 

-Rob

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Sun Oct 25 23:27:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Oct 2009 22:27:10 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256508896.14292.85.camel@lifeless-64>
Message-ID: <1256513466.5621.165.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Python 2.5 is also affected - its what we're running on the server that
> broke :) 

Yes, but it doesn't receive any bug fixes anymore -- only security
fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Sun Oct 25 23:34:17 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 25 Oct 2009 22:34:17 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256513466.5621.165.camel@localhost>
Message-ID: <1256510032.14292.86.camel@lifeless-64>


Robert Collins <robertc at robertcollins.net> added the comment:

On Sun, 2009-10-25 at 22:27 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> > Python 2.5 is also affected - its what we're running on the server that
> > broke :) 
> 
> Yes, but it doesn't receive any bug fixes anymore -- only security
> fixes.

Ok, we'll work around the issue there then ;)

-Rob

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Mon Oct 26 00:29:17 2009
From: report at bugs.python.org (Rich Healey)
Date: Sun, 25 Oct 2009 23:29:17 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>


New submission from Rich Healey <richo at psych0tik.net>:

64 bit pythons fail on 64 bit Windows 7.

The crash happens with python 2.6 and 3.1 in 64 bit mode. 3.1 was a
clean install after the issue presented itself.

I'm not 100% sure how best to help with the problem, I've attached the
dump from windows debugger, please let me know if there's anything else
I can do to help.

It used to work but I'm not sure what changed, as near as I can tell
nothing system wide did, except perhaps the installation of new
compilers, my thought is that it could alter some dll search path?

Thanks in advance

richo

----------
components: Interpreter Core
files: failedPython.log
messages: 94467
nosy: richo
severity: normal
status: open
title: 64 bit python fails on Windows 7
type: crash
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15197/failedPython.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 00:57:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Oct 2009 23:57:30 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256515050.09.0.543406265646.issue7206@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What is "LuaPriv" in that log? Something you installed?
(sorry, not a Windows specialist)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 00:58:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Oct 2009 23:58:01 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256515081.23.0.750108185164.issue7206@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Build, Windows
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 01:23:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2009 00:23:28 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1256516608.35.0.935425875453.issue7165@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think Antoine's suggestion is reasonable, and that we should apply the
patch to stop the buildbots from failing, but leave this issue open
until someone with more xmlrpc knowledge can respond to Nick and
Antoine's questions.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Mon Oct 26 02:29:21 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Oct 2009 01:29:21 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256520561.8.0.662639463107.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This new version of the patch provides a workaround for the issue1686475
regression. It simply falls back to the traditional (symlink-naive) stat
behavior when a handle cannot be obtained for the specified filename. 
My intention is that we can commit this patch (as it's still a strict
improvement over the previous behavior), and work out a fully-symlink
aware stat method in a subsequent patch.

There are still regression tests in test_posixpath.py that are failing
due to the non-implementation of realpath. I'll tackle this task next.

----------
Added file: http://bugs.python.org/file15198/windows symlink draft 11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 02:36:29 2009
From: report at bugs.python.org (Rich Healey)
Date: Mon, 26 Oct 2009 01:36:29 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256520989.48.0.472346565677.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

I'm not 100% sure.

I have a x64 machine running Windows 2008. I will check if it's in the
log now.

I will also check if it's in the debug trace for x86 python (which works).

RESULTS:

I get the LuaPriv initialised line on x86 python on my win7 machine
(which works).
I don't get that line on any python builds on x64 windows server 2008.

I did some googling on what it is- it's a mechanism for restricting
access. It seems that it could be causing the crash because it thinks
the application is overflowing the stack (ie, it's a DEP related issue?).
http://msdn.microsoft.com/en-us/library/dd371695(VS.85).aspx
That is a M$ link about it.

I'm fully willing to help but don't know how, I am quite novice.

Thanks


richo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 03:54:07 2009
From: report at bugs.python.org (Rich Healey)
Date: Mon, 26 Oct 2009 02:54:07 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256525647.38.0.0579718936505.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

I think that dump may be incorrect because it does not have all the
symbols. I will checkout source for latest 3.x trunk and attempt to
build 64 bit binaries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:32:51 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:32:51 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256535171.35.0.142485855892.issue7206@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What kind of action has triggered that crash?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:36:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:36:28 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535388.29.0.620488744909.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14009/windows symlink draft 1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:36:38 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:36:38 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535398.82.0.852040009152.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14039/windows symlink draft 2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:36:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:36:43 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535403.53.0.578486909361.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14050/windows symlink draft 3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:36:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:36:48 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535408.6.0.675260935191.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14130/windows symlink draft 4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:36:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:36:53 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535413.38.0.665418347715.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14195/windows symlink draft 5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:36:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:36:58 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535418.37.0.483732267897.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14206/windows symlink draft 6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:37:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:37:03 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535423.24.0.429708686452.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14837/python-core_rev4274.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:37:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:37:07 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535427.77.0.670181200205.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14838/python-core_rev4275.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:37:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:37:12 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535432.32.0.00822690959539.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14840/windows symlink draft 7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:37:17 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:37:17 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535437.35.0.25132859536.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14877/windows symlink draft 8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:37:23 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:37:23 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535443.9.0.0586426061587.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file14878/windows symlink draft 9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:37:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 05:37:30 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256535450.17.0.926054930778.issue1578269@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file15100/windows symlink draft 10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:45:18 2009
From: report at bugs.python.org (Rich Healey)
Date: Mon, 26 Oct 2009 05:45:18 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256535918.44.0.137620423297.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

No action- the interpreter fails to start.

Or do you mean what changed to make it break? I'm not sure. It used to
work but I don't believe I changed anything on my system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 08:15:11 2009
From: report at bugs.python.org (victorlee129)
Date: Mon, 26 Oct 2009 07:15:11 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1256541311.93.0.677679028494.issue6818@psf.upfronthosting.co.za>


victorlee129 <victorlee129 at gmail.com> added the comment:

I done it In a very *violent* way.
Is it ok for you thought?
if so, would anybody please fix it into the lib?

----------
components:  -IO
nosy: +victorlee129
versions: +Python 3.1 -Python 3.2
Added file: http://bugs.python.org/file15199/delete.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6818>
_______________________________________

From report at bugs.python.org  Mon Oct 26 08:51:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 07:51:26 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1256543486.31.0.681136269904.issue7165@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree with Antoine that CGIXML... is right in accessing
sys.stdout.buffer; this really needs binary IO.

Consequentially, his patch also looks right to me; please apply.

----------
assignee:  -> pitrou
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Mon Oct 26 08:53:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 07:53:08 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256535918.44.0.137620423297.issue7206@psf.upfronthosting.co.za>
Message-ID: <4AE55561.90207@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> No action- the interpreter fails to start.

How precisely do you start the interpreter (and what interpreter precisely)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 08:58:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 07:58:58 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1256541311.93.0.677679028494.issue6818@psf.upfronthosting.co.za>
Message-ID: <4AE556BF.8000809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I done it In a very *violent* way.
> Is it ok for you thought?

In the form in which you have done it, it is clearly
unacceptable for inclusion in the library: we don't
want to add two modules "delete" and "classtools".

In addition, notice that code is for tarfile, whereas
the OP was asking for a similar feature for zipfile.

> if so, would anybody please fix it into the lib?

This is not how this works. If you want us to take
action, please submit a complete and correct patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6818>
_______________________________________

From report at bugs.python.org  Mon Oct 26 09:30:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2009 08:30:30 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1256545830.27.0.635376524162.issue7165@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch applied in r75710.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Mon Oct 26 10:07:29 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 26 Oct 2009 09:07:29 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1256548049.57.0.822849999456.issue1602@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

Glenn Linderman's fix pretty well works for me on XP Home. I can print
every Unicode character up to and including U+D7FF (although most just
come out as rectangles, at least I don't get encoding errors).

It fails at U+D800 with message:

UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in
position 17: surrogates not allowed

I also tried U+D801 and got the same error.

Nonetheless, this is *much* better than before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Oct 26 10:15:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 09:15:12 +0000
Subject: [issue7207] test_telnetlib fails on OS X 10.6
In-Reply-To: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
Message-ID: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

test_telnetlib fails consistently on OS X 10.6, for a default (64-bit) 
build of py3k.  Test output below.

It looks to me as though this is just a race condition in the test 
(possibly combined with socket-related peculiarities of OS X) rather 
than a problem with telnetlib itself.  I suspect that the 'server' 
function in test_telnetlib.py is getting to the 'serv.close()' line 
prematurely, before all the test data from the 'test_write' test have 
been written.

Jack, I notice you've worked on these tests recently.  Any ideas?



testBasic (__main__.GeneralTests) ... ok
testTimeoutDefault (__main__.GeneralTests) ... ok
testTimeoutNone (__main__.GeneralTests) ... ok
testTimeoutOpen (__main__.GeneralTests) ... ok
testTimeoutValue (__main__.GeneralTests) ... ok
test_read_all_A (__main__.ReadTests) ... ok
test_read_all_B (__main__.ReadTests) ... ok
test_read_all_C (__main__.ReadTests) ... ok
test_read_eager_A (__main__.ReadTests) ... ok
test_read_eager_B (__main__.ReadTests) ... ok
test_read_lazy_A (__main__.ReadTests) ... ok
test_read_lazy_B (__main__.ReadTests) ... ok
test_read_some_A (__main__.ReadTests) ... ok
test_read_some_B (__main__.ReadTests) ... ok
test_read_some_C (__main__.ReadTests) ... ok
test_read_until_A (__main__.ReadTests) ... ok
test_read_until_B (__main__.ReadTests) ... ok
test_read_very_eager_A (__main__.ReadTests) ... ok
test_read_very_eager_B (__main__.ReadTests) ... ok
test_read_very_lazy_A (__main__.ReadTests) ... ok
test_read_very_lazy_B (__main__.ReadTests) ... ok
test_write (__main__.WriteTests) ... ERROR
test_IAC_commands (__main__.OptionTests) ... ok
test_SB_commands (__main__.OptionTests) ... ok
test_debuglevel_reads (__main__.OptionTests) ... ok
test_debuglevel_write (__main__.OptionTests) ... ok

======================================================================
ERROR: test_write (__main__.WriteTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_telnetlib.py", line 347, in test_write
    self._test_write(d)
  File "Lib/test/test_telnetlib.py", line 332, in _test_write
    self.telnet.write(data)
  File "/Users/dickinsm/python/svn/py3k/Lib/telnetlib.py", line 280, in 
write
    self.sock.sendall(buffer)
  File "Lib/test/test_telnetlib.py", line 317, in sendall
    self.socket.sendall(data)
socket.error: [Errno 32] Broken pipe

----------------------------------------------------------------------
Ran 26 tests in 10.179s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_telnetlib.py", line 470, in <module>
    test_main()
  File "Lib/test/test_telnetlib.py", line 467, in test_main
    support.run_unittest(GeneralTests, ReadTests, WriteTests, 
OptionTests)
  File "/Users/dickinsm/python/svn/py3k/Lib/test/support.py", line 911, 
in run_unittest
    _run_suite(suite)
  File "/Users/dickinsm/python/svn/py3k/Lib/test/support.py", line 894, 
in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_telnetlib.py", line 347, in test_write
    self._test_write(d)
  File "Lib/test/test_telnetlib.py", line 332, in _test_write
    self.telnet.write(data)
  File "/Users/dickinsm/python/svn/py3k/Lib/telnetlib.py", line 280, in 
write
    self.sock.sendall(buffer)
  File "Lib/test/test_telnetlib.py", line 317, in sendall
    self.socket.sendall(data)
socket.error: [Errno 32] Broken pipe

----------
components: Tests
messages: 94481
nosy: jackdied, mark.dickinson
severity: normal
stage: needs patch
status: open
title: test_telnetlib fails on OS X 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7207>
_______________________________________

From report at bugs.python.org  Mon Oct 26 10:18:57 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 26 Oct 2009 09:18:57 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1256548737.57.0.517292333613.issue7169@psf.upfronthosting.co.za>


Ryan Leslie <rylesny at gmail.com> added the comment:

I expect this should already be fixed by the commit in
http://bugs.python.org/issue6511

BadZipFile will now be raised for empty files rather than IOError, and
so ZipFile._GetContents() should now also close the file.

The fix was committed to trunk, but I don't see it merged into 2.6.

----------
nosy: +amaury.forgeotdarc, ryles

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Mon Oct 26 10:19:57 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 26 Oct 2009 09:19:57 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1256548049.57.0.822849999456.issue1602@psf.upfronthosting.co.za>
Message-ID: <4AE569B8.4020700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Summerfield wrote:
> 
> Mark Summerfield <mark at qtrac.eu> added the comment:
> 
> Glenn Linderman's fix pretty well works for me on XP Home. I can print
> every Unicode character up to and including U+D7FF (although most just
> come out as rectangles, at least I don't get encoding errors).
> 
> It fails at U+D800 with message:
> 
> UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in
> position 17: surrogates not allowed
> 
> I also tried U+D801 and got the same error.

That's normal and expected: D800 is the start of the surrogate
ranges which are only allows in pairs in UTF-8.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Oct 26 11:00:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 10:00:44 +0000
Subject: [issue7207] test_telnetlib fails on OS X 10.6
In-Reply-To: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
Message-ID: <1256551244.03.0.191101974426.issue7207@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that fixes the problem for me.  For each of the tests 
defined in WriteTests (there's only one at the moment), it forces the 
server to wait until the test is complete before closing the connection.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15200/issue7207.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7207>
_______________________________________

From report at bugs.python.org  Mon Oct 26 11:26:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 10:26:38 +0000
Subject: [issue7207] test_telnetlib fails on OS X 10.6
In-Reply-To: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
Message-ID: <1256552798.1.0.0629460019041.issue7207@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Assigning to Jack for review.

----------
assignee:  -> jackdied
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7207>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:42:30 2009
From: report at bugs.python.org (skelker)
Date: Mon, 26 Oct 2009 12:42:30 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1256548737.57.0.517292333613.issue7169@psf.upfronthosting.co.za>
Message-ID: <52C333133934CA4585938535BE63885C16F49D5D@EX02.dtn.com>


skelker <steve.kelker at dtn.com> added the comment:

Thanks.  I did do a search before opening my ticket.  Not sure why I didn't see that in my search. Sorry for the duplicate ticket.

Steve Kelker
(952)882-4381 (or x4381)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:43:53 2009
From: report at bugs.python.org (skelker)
Date: Mon, 26 Oct 2009 12:43:53 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1256561033.78.0.664927420966.issue7169@psf.upfronthosting.co.za>


skelker <steve.kelker at dtn.com> added the comment:

Fixed in http://bugs.python.org/issue6511

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Mon Oct 26 15:39:39 2009
From: report at bugs.python.org (Peter Saunders)
Date: Mon, 26 Oct 2009 14:39:39 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>


New submission from Peter Saunders <pajs at fodder.org.uk>:

Only sucessfully replicated on solaris.

When running getpass() - it goes into non echo mode, however, once enter
is pressed, the password is echoed to the screen. E.g.

> /opt/python/2.6.3/bin/python -c 'import getpass; x=getpass.getpass()'
Password: bob

This does NOT happen on older versions:
> /opt/IBpython/2.5.1/bin/python -c 'import getpass; x=getpass.getpass()'
Password:

/opt/python/2.3.3/bin/python -c 'import getpass; x=getpass.getpass()'
Password:

To stop this occuring for me, simply adding a stream.flush() line
straight after the 

            finally:
                termios.tcsetattr(fd, termios.TCSADRAIN, old)

line fixes the issue:
saundep at ln8u3494inx:[/tmp]> /opt/IBpython/2.6.3/bin/python -c 'import
gp; gp.getpass()'
Password:

----------
components: Library (Lib)
messages: 94488
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Mon Oct 26 15:49:19 2009
From: report at bugs.python.org (Peter Saunders)
Date: Mon, 26 Oct 2009 14:49:19 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1256568559.41.0.21903711981.issue7208@psf.upfronthosting.co.za>


Changes by Peter Saunders <pajs at fodder.org.uk>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15201/getpass.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:14:35 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Oct 2009 15:14:35 +0000
Subject: [issue3223] py3k warn on use of frame.f_exc*
In-Reply-To: <1214600469.72.0.692863353975.issue3223@psf.upfronthosting.co.za>
Message-ID: <1256570075.78.0.428612956562.issue3223@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This was fixed in r67902.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3223>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:23:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 15:23:04 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1256570584.51.0.341702801362.issue7208@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a critical bug, thanks.

----------
nosy: +pitrou
priority:  -> critical
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Mon Oct 26 17:03:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 16:03:27 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256573007.2.0.340526313444.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r75720: Backport py3k version of pystrtod.c to trunk.  There are still
        some (necessary) differences between the two versions, which
        should become unnecessary once everything else is hooked up.
        The differences should be re-examined later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Oct 26 17:58:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 26 Oct 2009 16:58:45 +0000
Subject: [issue7157] Fix Download Current Documentation link
In-Reply-To: <1255740019.91.0.5088264353.issue7157@psf.upfronthosting.co.za>
Message-ID: <1256576325.34.0.0634524176639.issue7157@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed now that 2.6.4 is final.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7157>
_______________________________________

From report at bugs.python.org  Mon Oct 26 17:59:35 2009
From: report at bugs.python.org (Matt Kraai)
Date: Mon, 26 Oct 2009 16:59:35 +0000
Subject: [issue7209] Prevents uint_t from being used on QNX
In-Reply-To: <1256576375.9.0.147496102309.issue7209@psf.upfronthosting.co.za>
Message-ID: <1256576375.9.0.147496102309.issue7209@psf.upfronthosting.co.za>


New submission from Matt Kraai <kraai at ftbfs.org>:

pyconfig.h defines _POSIX_C_SOURCE to 200112L, which prevents QNX's
sys/types.h from defining uint_t.  Samba 4 uses this type, so it fails
to compile if Python.h is included first (cf.
https://bugzilla.samba.org/show_bug.cgi?id=6842).

The attached patch fixes this issue by defining _QNX_SOURCE.

----------
components: Build
files: define-_QNX_SOURCE.patch
keywords: patch
messages: 94493
nosy: kraai
severity: normal
status: open
title: Prevents uint_t from being used on QNX
versions: Python 2.7
Added file: http://bugs.python.org/file15202/define-_QNX_SOURCE.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7209>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:01:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 17:01:11 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256576471.3.0.25401666186.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Eric, on removing f to g conversions]
> Should we also do that as part of this exercise? Or should it be another
> issue, or not done at all?

I'd definitely like to remove the f to g conversion in trunk.  I don't 
see any great need to open a separate issue for that.  (Was there one 
already for the py3k removal?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:03:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 17:03:18 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256576598.17.0.112493954643.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Found it: issue #5859 was opened for the removal of the f -> g conversion 
in py3k.  We could just add a note to that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:06:22 2009
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 26 Oct 2009 17:06:22 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1256576782.64.0.795455535075.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

The choice of the Lucida Consola or the Consolas font cures most of the
rectangle problems.  Those are just a limitation of the selected font
for the console window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:39:28 2009
From: report at bugs.python.org (Matt Kraai)
Date: Mon, 26 Oct 2009 17:39:28 +0000
Subject: [issue7209] Prevents uint_t from being used on QNX
In-Reply-To: <1256576375.9.0.147496102309.issue7209@psf.upfronthosting.co.za>
Message-ID: <1256578767.97.0.701226046495.issue7209@psf.upfronthosting.co.za>


Matt Kraai <kraai at ftbfs.org> added the comment:

Here's an updated patch.  The first time I forgot to regenerate
pyconfig.h.in.

----------
Added file: http://bugs.python.org/file15203/define-_QNX_SOURCE.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7209>
_______________________________________

From report at bugs.python.org  Mon Oct 26 19:22:40 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Oct 2009 18:22:40 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256581360.23.0.147949873255.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This latest patch (12) adds os.readlink(). Unfortunately, this causes
more tests in test_posixpath.py to break. I'll continue to investigate.

----------
Added file: http://bugs.python.org/file15204/windows symlink draft 12.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 19:53:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 18:53:03 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1256441829.21.0.642723106535.issue1625@psf.upfronthosting.co.za>
Message-ID: <1256587019.3923.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That was mostly just out of paranoia, since the comments mentioned 
> multiple calls to close being legal.  Looking at it again, that particular 
> case isn't an issue, since we don't hit that call when the mode is 
> MODE_CLOSED.  The testsuite runs happily with those changes reverted.  
> Should I upload a new patch?

You don't need to, but on the other hand I forgot to ask you to update
the documentation :-) (see Doc/library/bz2.rst)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon Oct 26 20:23:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 19:23:10 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256584990.09.0.997284577978.issue7205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file15205/bzthreads.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Mon Oct 26 20:40:20 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Mon, 26 Oct 2009 19:40:20 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>


New submission from Chuck Rhode <CRhode at LacusVeris.com>:

PythonTidy is a code beautifier written three years ago and downloaded
numerous times.

o http://lacusveris.com/PythonTidy/PythonTidy.python

It suffers a bug, which has only recently come to light.  It considers
the following lines equivalent:

  if False is (2 is 3): pass

  if False is 2 is 3: pass

They're not.  PythonTidy handles other non-associative operators such as
division correctly.  I was unable to generalize from arithmetic
operators to comparison operators because the Abstract Syntax Tree (AST)
generated by the *compiler* module returns a different structure for them.  

I tested PythonTidy by running the Python Test Suite (the *test* module
scripts) through it and executing the results, thought I had all my
bases covered because most tests succeeded, and missed this case, so I
am suggesting an amplification of the Python Test Suite for developers
who may be using it for purposes other than testing Python.

I wish to add these lines to the foot of *test_grammar.py*.

  verify(16 // (4 // 2) == 8, '16 // (4 // 2) == 8')
  verify((16 // 4) // 2 == 2, '(16 // 4) // 2 == 2')
  verify(16 // 4 // 2 == 2, '16 // 4 // 2 == 2')
  verify((False is (2 is 3)) == True, '(False is (2 is 3)) == True')
  verify(((False is 2) is 3) == False, '(((False is 2) is 3) == False')
  verify((False is 2 is 3) == False, '(False is 2 is 3) == False')

----------
components: Tests
files: test_grammar.patch
keywords: patch
messages: 94501
nosy: ChuckRhode
severity: normal
status: open
title: Proposed Syntax Checks in Test Suite
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file15206/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Mon Oct 26 20:54:43 2009
From: report at bugs.python.org (Michael Broghton)
Date: Mon, 26 Oct 2009 19:54:43 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>


New submission from Michael Broghton <mbroughton at advanis.ca>:

On FreeBSD and MacOS 64-bit systems the ident field of a kevent is big
enough to hold a 64-bit integer (uintptr_t). Looks like Python is
casting it to an unsigned 32-bit integer.

This is inconvenient for implementing kqueue timers, where id(timer_obj)
is a natural choice for an ident.

----------
components: Library (Lib)
messages: 94502
nosy: mbroughton
severity: normal
status: open
title: select module - kevent ident field 64 bit issue
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Mon Oct 26 21:01:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 20:01:40 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256587300.47.0.69715286377.issue7211@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes, therve

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Mon Oct 26 21:01:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 20:01:54 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256587314.52.0.303659091098.issue7211@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Mon Oct 26 21:16:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Oct 2009 20:16:04 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256588164.3.0.193579378856.issue7210@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please provided a unified diff against the trunk.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Mon Oct 26 21:28:15 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 20:28:15 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256588895.5.0.94534415844.issue7211@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to propose a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Mon Oct 26 21:33:22 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 20:33:22 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1256589202.19.0.395936505904.issue7071@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Done in trunk (r75669, and r75670 and r75671) and Py3k (r75704) and 3.1
(r75705). 

I'll push in 2.6 when the branch is unfrozen.

Michael, could you create another issue for the access rights problems ? 
It'll be easier to track.

Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________

From report at bugs.python.org  Mon Oct 26 21:57:07 2009
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Augustsson?=)
Date: Mon, 26 Oct 2009 20:57:07 +0000
Subject: [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256066361.67.0.856908036986.issue7176@psf.upfronthosting.co.za>
Message-ID: <7d4a02d80910261357k231f4569r5b95c16df18043a1@mail.gmail.com>


Bj?rn Augustsson <oggust at gmail.com> added the comment:

On Tue, Oct 20, 2009 at 20:19, Raymond Hettinger <report at bugs.python.org> wrote:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> One use of the start argument is used to specify an initial zero/metpy
> value for the summation: ?0 ?or ?0.0 ? or Decimal(0) ?or ?[].

That means it's basically a way for you to tell sum() what the type of the
first argument is. Which it could find out for itself.

> BTW, sum() isn't a good technique for concatenating lists. ?Instead use
> something like:
>
> ? result = []
> ? for seq in data:
> ? ? ?result.extend(seq)
>
> A fast one-liner version:
> ? result = list(itertools.chain.from_iterable(seq))

IMHO there's no reason for sum() not to be as fast as possible at doing
what it does. ("summing"). If it's somehow slower than the (way less readable)
itertools incantation above, then I'd consider that to be a bug.

/August.
-- 
Wrong on most accounts.  const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo.  const Foo const *foo; would mean the same but is
illegal (double const).  You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:01:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2009 21:01:44 +0000
Subject: [issue7176] sum() doesn't work for lists.
In-Reply-To: <1256046536.74.0.518761053354.issue7176@psf.upfronthosting.co.za>
Message-ID: <1256590904.37.0.373572334297.issue7176@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7176>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:06:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 26 Oct 2009 21:06:58 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256591218.1.0.454452411154.issue7175@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FYI, /etc/pythonX.Y (and /etc/python) are used by Debian; the former
contains site.py and sitecustomize.py, the latter a file called
debain_config.

I can't see how this could become a problem, but maybe someone else does.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:07:19 2009
From: report at bugs.python.org (Willi Richert)
Date: Mon, 26 Oct 2009 21:07:19 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>


New submission from Willi Richert <w.richert at gmx.net>:

Sometimes, a non-removing pop() is needed. In current Python versions,
it can achieved by one of the following ways:

1. 
x = some_set.pop()
some_set.add(x)

2. 
for x in some_set: 
        break

3.
x = iter(some_set).next()

More native and clean would, however, be 
some_set.get()

The attached patch does this for set(). If this is accepted by the
community, frozenset should be extended as well.

----------
components: Library (Lib)
files: setobject_get.patch
keywords: patch
messages: 94508
nosy: wrichert
severity: normal
status: open
title: Retrieve an arbitrary element from a set without removing it
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15207/setobject_get.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:12:13 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Oct 2009 21:12:13 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256591533.12.0.647349500755.issue7212@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:15:15 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 26 Oct 2009 21:15:15 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256584990.09.0.997284577978.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256591705.7720.4.camel@lifeless-64>


Robert Collins <robertc at robertcollins.net> added the comment:

On Mon, 2009-10-26 at 19:23 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Here is a patch.

Looks fine to me assuming that the locking functions can be used outside
the GIL.

On the test side, the case I supplied was low noise for me - I'd
hesitate to do as much compression as you are (50 times more) unless you
saw it spuriously pass a lot - the nature of the deadlock isn't
dependent on races so much as simple scheduling - as long as the seocnd
thread is scheduled before the first thread completes compressing the
deadlock will occur.

-Rob

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:19:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 21:19:18 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256591958.95.0.0891573335101.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r75730: backport pystrtod.h
r75731: Fix floatobject.c to use PyOS_string_to_double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:22:43 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Oct 2009 21:22:43 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256592163.21.0.427924135398.issue7212@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Without tests, this patch is unacceptable.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:27:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 21:27:34 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256591705.7720.4.camel@lifeless-64>
Message-ID: <1256596288.3923.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Looks fine to me assuming that the locking functions can be used outside
> the GIL.

Yes, they can. Actually, even the GIL uses them. :-)

> On the test side, the case I supplied was low noise for me - I'd
> hesitate to do as much compression as you are (50 times more) unless you
> saw it spuriously pass a lot - the nature of the deadlock isn't
> dependent on races so much as simple scheduling - as long as the seocnd
> thread is scheduled before the first thread completes compressing the
> deadlock will occur.

Well, your test case often succeeded here, so I decided on a more
aggressive variation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:30:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Oct 2009 21:30:16 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256592616.75.0.838596287414.issue7203@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r75734.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:30:21 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Oct 2009 21:30:21 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1256592621.13.0.503016969853.issue7165@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fine by me (I was very close to changing the test when I first triggered
the problem, but wasn't sure silencing the error was the right thing to do).

Assigning back to myself to add a comment to the relevant line (i.e.
that relying on the buffer attribute being present is a deliberate
design choice).

----------
assignee: pitrou -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:31:17 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Oct 2009 21:31:17 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256592677.46.0.44789724039.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15198/windows symlink draft 11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:33:18 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 26 Oct 2009 21:33:18 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256596288.3923.11.camel@localhost>
Message-ID: <1256592776.7720.6.camel@lifeless-64>


Robert Collins <robertc at robertcollins.net> added the comment:

On Mon, 2009-10-26 at 21:27 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, your test case often succeeded here, so I decided on a more
> aggressive variation.

fair enough, if its needed - its needed :)

-Rob

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:46:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Oct 2009 21:46:10 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1256592621.13.0.503016969853.issue7165@psf.upfronthosting.co.za>
Message-ID: <1256597405.3923.13.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Assigning back to myself to add a comment to the relevant line (i.e.
> that relying on the buffer attribute being present is a deliberate
> design choice).

The remaining question, however, is why it doesn't also rely on
stdin.buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:47:03 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Oct 2009 21:47:03 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256593623.44.0.0243283084742.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This latest patch (13) addresses the regressions in test_posixpath.py by
repeating a technique found in the new lstat. That is, if a handle can't
be obtained for GetFinalPathNameByHandle (because the target is in use),
it is assumed that the target does in fact exist and the attributes are
retrieved from the parent directory.

----------
Added file: http://bugs.python.org/file15208/windows symlink draft 13.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:49:35 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Oct 2009 21:49:35 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256593775.95.0.746212660995.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15204/windows symlink draft 12.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:01:01 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 22:01:01 +0000
Subject: [issue7202] "python setup.py MYCOMMAND --verbose" does not yield an
	unrecognized option error but also does not set the verbosity
In-Reply-To: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
Message-ID: <1256594461.43.0.305135301991.issue7202@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

There's this comment in dist.py:

# All commands support the global options too, just by adding
# in 'global_options'.

So, that's a bug. I'll do this:

- if a command has a global option (except help) it will be reapplied to
the distribtuion object

- if a command has a global option (except help) but also defines it as
a local command option, it will not be reapplied to the distribtuion object

- if a command has a global option (except help) and it was already
provided at the regular place, it will be ignored and a warning will be
displayed.

----------
priority:  -> normal
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7202>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:04:28 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 22:04:28 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256594668.02.0.93723436979.issue7175@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the info Georges.

I am adding Matthias and Michael so they can give us their opinions for
their platforms (Debian/Ubuntu and Win)

----------
nosy: +doko, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:08:53 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 22:08:53 +0000
Subject: [issue6992] PEP 314 inconsistency (authors/author/maintainer)
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1256594933.54.0.27483423982.issue6992@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This discussion is taken to distutils-SIG, and a PEP 345 update is being
worked out there. (look for 'RFC PEP 345' in Distutils archives)

I am closing this issue and proposes that we continue there.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:10:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 22:10:39 +0000
Subject: [issue7131] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1255547923.17.0.905503258872.issue7131@psf.upfronthosting.co.za>
Message-ID: <1256595039.92.0.673605315343.issue7131@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the feedback, this was detected as a regression and fixed in
the upcoming 2.6.4

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7131>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:12:05 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Oct 2009 22:12:05 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256595125.66.0.147216424109.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The problem I'm encountering now is tests for posixpath.realpath are
failing on Windows. These tests were previously skipped under Windows
because there was no os.symlink. Now that Windows has os.symlink, these
regression tests fail (test_realpath_basic,
test_realpath_resolve_before_normalizing, test_realpath_resolve_first,
and test_realpath_resolve_parent).

What is the correct fix for this? Should posixpath.realpath work on
Windows? If not, should the tests just be ignored under Windows?
Otherwise, should posixpath.realpath be rewritten to be robust under
both operating systems? Or is there another approach?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:12:45 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 26 Oct 2009 22:12:45 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256595165.33.0.56351124116.issue7175@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Personally I'm uncomfortable with creating
yet-another-location-for-config-files.

As we now have is ~/.local/pythonX.Y I would reuse this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:17:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 22:17:42 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1256595462.91.0.91265435096.issue1054967@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am closing this issue, since stdeb implements this command now.

Also, I'd love to add it in the distutils documentation, but there's one
issue.

Andrew, do you think you could have a plain distutils version of this
command ? 

Setuptools changes the Command and the Distribution classes, and affects
Distutils global behavior, so we can't document its usage in the
Distutils documentation as it is.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:23:40 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 26 Oct 2009 22:23:40 +0000
Subject: [issue7207] test_telnetlib fails on OS X 10.6
In-Reply-To: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
Message-ID: <1256595820.46.0.659857336269.issue7207@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Looks good and works for me, please check it in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7207>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:24:14 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Oct 2009 22:24:14 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1256595854.1.0.898289813008.issue6860@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

It's a bit more complicated.

the option you are desrcibing it just one way to register commands in fact.

Distutils also has a discovery function that will load commands from
packages, and that's where the biggest issue is.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:28:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 26 Oct 2009 22:28:34 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256596114.19.0.468101175781.issue7175@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

But ~/.local is simply not the location for config files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:30:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 22:30:03 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256596203.94.0.0159649664188.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r75739: Fix complexobject.c to use PyOS_string_to_double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:34:34 2009
From: report at bugs.python.org (Michael Broghton)
Date: Mon, 26 Oct 2009 22:34:34 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256596474.09.0.0106151031407.issue7211@psf.upfronthosting.co.za>


Michael Broghton <mbroughton at advanis.ca> added the comment:

I'm not sure how to patch this so that it will work on both 32 and 64
bit systems. Issues:

1. What would be an appropriate member type for ident in
kqueue_event_members? It seems like T_PYSSIZET might work. Otherwise, I
am guessing that this will involve some #if's.

2. I think the format spec in kqueue_event_repr needs to change. It
seems like this will also require some #if's.

3. kqueue_event_init uses PyObject_AsFileDescriptor to set the ident
field. This should be doing a PyLong_Check first to see if
PyLong_AsSomething would be more appropriate.

4. I think the type of the result variable in kqueue_event_richcompare
needs to be changed to long long int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:35:37 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 26 Oct 2009 22:35:37 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256596537.96.0.834180736287.issue7175@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

For Linux and Mac OS X put the config file wherever the 'right' place is
then, but we are starting to create a lot of new directories disparate
from the actual install. Oh well.

On Windows we create: %APPDATA%/Python/PythonX.Y/site-packages

If it is to no longer live inside distutils (which seems reasonable)
then on Windoze a 'good' place would seem to be: %APPDATA%/Python/PythonX.Y/

On Windows there is no 'right' place, the officially right place for the
system is probably the registry but I don't think many Python
programmers would thank you for that...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:36:39 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 26 Oct 2009 22:36:39 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256596599.71.0.206785187699.issue7175@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Noting of course that on IronPython it should be:
%APPDATA%/IronPython/PythonX.Y/

or wherever we decided in the end. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:36:46 2009
From: report at bugs.python.org (Rich Healey)
Date: Mon, 26 Oct 2009 22:36:46 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256596606.13.0.036052356956.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

By running the python.exe (either by double clicking it, typing it's
path into a cmd shell or by opening it in a debugger).

I tried to create a 64 bit build of the source tree which DID start, but
the hoops I had to jump through to build it with VC++ Express Edition
were so convoluted that I'm not convinced it's meaning.

I've tried this with 2.6.3 and 3.1.1 from the amd64 .msi's at
http://www.python.org/download/

(2.6.3 was the current release when I tried. I will install 2.6.4 and
let you know- although I'm not convinced it will help).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:40:14 2009
From: report at bugs.python.org (Rich Healey)
Date: Mon, 26 Oct 2009 22:40:14 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256596814.17.0.154917844913.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

Nope- 2.6.4 fails in the same way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:48:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 22:48:43 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256596474.09.0.0106151031407.issue7211@psf.upfronthosting.co.za>
Message-ID: <4AE62745.7080600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 1. What would be an appropriate member type for ident in
> kqueue_event_members? It seems like T_PYSSIZET might work. Otherwise, I
> am guessing that this will involve some #if's.

IIUC, it needs to match *exactly* the field size inside struct kevent.
So you'll have to use #ifs, possible along with autoconf tests (to
find out the sizes of the fields that typically vary across
implementations).

> 2. I think the format spec in kqueue_event_repr needs to change. It
> seems like this will also require some #if's.

Here, I would widen the fields to size_t, and use the size_t formatter
(assuming that all systems supporting kqueue also know how to print
size_t, or know to print long long).

> 3. kqueue_event_init uses PyObject_AsFileDescriptor to set the ident
> field. This should be doing a PyLong_Check first to see if
> PyLong_AsSomething would be more appropriate.

Hmm. I think I need to understand the use case better. Can you post
some sample code where this all matters?

If this *is* a regular file-like object, then surely int is enough, no?

> 4. I think the type of the result variable in kqueue_event_richcompare
> needs to be changed to long long int.

Fine with me. The question then is whether long long is available on
all systems that support kqueue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:49:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Oct 2009 22:49:22 +0000
Subject: [issue7207] test_telnetlib fails on OS X 10.6
In-Reply-To: <1256548512.29.0.936699598359.issue7207@psf.upfronthosting.co.za>
Message-ID: <1256597362.21.0.737427644742.issue7207@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Jack.  Applied in r75741.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7207>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:49:49 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Oct 2009 22:49:49 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256597389.47.0.294319696407.issue7206@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

FWIW, these all run fine on my copy of Windows 7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:57:57 2009
From: report at bugs.python.org (Rich Healey)
Date: Mon, 26 Oct 2009 22:57:57 +0000
Subject: [issue7206] 64 bit python fails on Windows 7
In-Reply-To: <1256513357.48.0.845070518085.issue7206@psf.upfronthosting.co.za>
Message-ID: <1256597877.5.0.566053720099.issue7206@psf.upfronthosting.co.za>


Rich Healey <richo at psych0tik.net> added the comment:

They did at first for me, and then something changed.

They now don't start. I don't have the skills to properly diagnose why,
all I can get out of my debuggers is that something is happening in
ntdll.dll

Not necessarily pointing fault at Python per se, but as it's the only
application I can find this bug in, and it's present in every amd64
version of Dolphin I try this is my first port of call.

What other info can I provide to help? I can set up a remote desktop to
this machine for a developer if they would like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7206>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:14:02 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 26 Oct 2009 23:14:02 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>


New submission from Milko Krachounov <python at milko.3mhz.net>:

Currently, close_fds defaults to False. The are few cases in which one
would want to leave the fds open, in all the rest leaving them open can
lead to unpleasant side effects. For example, the following doesn't work:

>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE)
>>> p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE)
>>> p1.stdin.write("aaaaaaaaaaaaaaaa\n")
>>> p1.stdin.close()
>>> p2.stdout.read()

It would block forever, and it is not obvious that p1.stdin remains
open, because p2 was created without close_fds=True. On the other hand,
in each and every case where close_fds=True is required, the programmer
is aware that he needs to leave some fds open (and usually knows which fds).

The current default is harmful, because in each case where the file
descriptors are not explicitly needed in the child process, they can
cause problems hard to debug. It seems that only about 10% of the
current uses of Popen have close_fds=True.

I propose that the close_fds default is changed to True. Alternatively,
this could be combined with bug #6559 by completely removing the
close_fds argument, and leaving only pass_fds, which could accept
subprocess.ALL_FDS as a value.

There are two issues with my proposal:
1. close_fds would have to be changed to give a warning each time it is
not specified before the change of the default can be adopted. Otherwise
it would break any programs relying on close_fds being False by default.
2. Closing fds has a slight performance impact.

However, I think that close_fds=True is much more sensible default. I
think it will be a good idea if at least py3k adopts the change.

----------
components: Library (Lib)
messages: 94538
nosy: milko.krachounov
severity: normal
status: open
title: Popen.subprocess change close_fds default to True
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:14:56 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Mon, 26 Oct 2009 23:14:56 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256598896.5.0.0469551885183.issue7210@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

You mean like this?

----------
Added file: http://bugs.python.org/file15209/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:17:50 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Mon, 26 Oct 2009 23:17:50 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256599070.6.0.816522502645.issue7210@psf.upfronthosting.co.za>


Changes by Chuck Rhode <CRhode at LacusVeris.com>:


Removed file: http://bugs.python.org/file15209/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:23:54 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Mon, 26 Oct 2009 23:23:54 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256599434.82.0.688504184486.issue7210@psf.upfronthosting.co.za>


Changes by Chuck Rhode <CRhode at LacusVeris.com>:


Removed file: http://bugs.python.org/file15206/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:25:38 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Mon, 26 Oct 2009 23:25:38 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256599538.2.0.498026650413.issue7210@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

Well, the last two patch files weren't very good, but I hope the third
time's the charm.

----------
Added file: http://bugs.python.org/file15210/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:27:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Oct 2009 23:27:16 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256599636.91.0.0320353396828.issue7210@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

That still looks like it's against Python 2.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:32:30 2009
From: report at bugs.python.org (Brian)
Date: Mon, 26 Oct 2009 23:32:30 +0000
Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
Message-ID: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>


New submission from Brian <brian at merrells.org>:

In the pure python ElementTree, the tag passed to the end() tag is
verified to be closing the last tag opened (self._last).

This cElementTree performs no such validation and closes the last tag
regardless of what tag is passed to the method.

In my mind this raises a couple questions beyond simply fixing this
discrepancy.
1)  Why make this tag mandatory if it has no effect in the cElementTree
version (and in the pure python version is only used to verify the user
isn't confused what tag they are closing)
2)  Could the argument be removed, simply closing the last tag if not
present?
3)  Or could the behavior be changed to actually influence which tag is
closed, allowing one to close all tags out to a specific
outer/encompassing tag (much like close(), closes all tags)?

-brian

----------
components: Library (Lib)
messages: 94542
nosy: merrellb
severity: normal
status: open
title: TreeBuilder.end(tag) differs between cElementTree and ElementTree
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:32:33 2009
From: report at bugs.python.org (Brian)
Date: Mon, 26 Oct 2009 23:32:33 +0000
Subject: [issue7215] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599953.85.0.50468157726.issue7215@psf.upfronthosting.co.za>
Message-ID: <1256599953.85.0.50468157726.issue7215@psf.upfronthosting.co.za>


New submission from Brian <brian at merrells.org>:

In the pure python ElementTree, the tag passed to the end() tag is
verified to be closing the last tag opened (self._last).

This cElementTree performs no such validation and closes the last tag
regardless of what tag is passed to the method.

In my mind this raises a couple questions beyond simply fixing this
discrepancy.
1)  Why make this tag mandatory if it has no effect in the cElementTree
version (and in the pure python version is only used to verify the user
isn't confused what tag they are closing)
2)  Could the argument be removed, simply closing the last tag if not
present?
3)  Or could the behavior be changed to actually influence which tag is
closed, allowing one to close all tags out to a specific
outer/encompassing tag (much like close(), closes all tags)?

-brian

----------
components: Library (Lib)
messages: 94543
nosy: merrellb
severity: normal
status: open
title: TreeBuilder.end(tag) differs between cElementTree and ElementTree
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7215>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:33:36 2009
From: report at bugs.python.org (Brian)
Date: Mon, 26 Oct 2009 23:33:36 +0000
Subject: [issue7215] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599953.85.0.50468157726.issue7215@psf.upfronthosting.co.za>
Message-ID: <1256600016.84.0.699557847135.issue7215@psf.upfronthosting.co.za>


Changes by Brian <brian at merrells.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7215>
_______________________________________

From report at bugs.python.org  Tue Oct 27 01:52:07 2009
From: report at bugs.python.org (Michael Broghton)
Date: Tue, 27 Oct 2009 00:52:07 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256604727.82.0.602372469923.issue7211@psf.upfronthosting.co.za>


Michael Broghton <mbroughton at advanis.ca> added the comment:

Martin, thanks for your responses. In regards to point three:

Kqueue's are not just used for file descriptors. I believe this is the
reason why the ident field is a uintptr_t and not an int.

The example I gave was for kqueue timers. Since the operating system
does not allocate 'timer descriptors' for you, I decided to use the
return value from the id function.

Here is some code that demonstrates:

import select
a = 1
b = id(a)
c = select.kevent(a)
d = select.kevent(b)
assert a == c.ident
assert b == d.ident
assert b & (1<<32) - 1 == d.ident

The second assert will fail on 64 bit systems if 'b' is too big.

Anyway, I will try to come up with a patch for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Tue Oct 27 02:40:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2009 01:40:40 +0000
Subject: [issue7215] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599953.85.0.50468157726.issue7215@psf.upfronthosting.co.za>
Message-ID: <1256607640.58.0.735410369679.issue7215@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> low
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> TreeBuilder.end(tag) differs between cElementTree and ElementTree

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7215>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:13:52 2009
From: report at bugs.python.org (Volker Siepmann)
Date: Tue, 27 Oct 2009 07:13:52 +0000
Subject: [issue7216] low performance of zipfile readline()
In-Reply-To: <1256627631.57.0.724869251337.issue7216@psf.upfronthosting.co.za>
Message-ID: <1256627631.57.0.724869251337.issue7216@psf.upfronthosting.co.za>


New submission from Volker Siepmann <newsgroups at vsiep.de>:

The readline() function in zipfile (in ZipExtFile) reads chunks of max
100 bytes (zipfile.py, line 525) into the linebuffer. A file of 500
MBytes therefore yields 5 million chunks.
Changing the value 100 to 10000 bytes boosts performance by magnitudes,
while it only requires 10k of memory.

My fix in zipfile.py, line 525:

buf = self.read(min(size, 10000)) # was 100 before

Best regards / Volker Siepmann

----------
components: Library (Lib)
messages: 94545
nosy: volker_siepmann
severity: normal
status: open
title: low performance of zipfile readline()
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7216>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:57:06 2009
From: report at bugs.python.org (ali)
Date: Tue, 27 Oct 2009 07:57:06 +0000
Subject: [issue7217] IDLE Subprocess Startup Error
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>


New submission from ali <mr.dalba at gmail.com>:

Hi

After trying to install another IDE for python (Eric4.3.8 and sciTE201)
I'm not able to launch IDLE directly anymore. (I not sure if this is
really relevant)

I can right click on the .py files and choose "edit with IDLE" and
everything works fine.

Also, I can run python under cmd without any problem.

But when I try to open IDLE using start menu icon, this error massage
appears:

Subprocess Startup Error
IDLE's subprocess didn't make connection. either idle can't start a
subprocess or personal firewall software is blocking the connection.

I tried to disable my anti-virus and windows firewall (I don't use any
other firewalls), but the problem still exists.

I uninstalled python 2.6.2 and then installed python 3.1.1. IDLE worked
fine but I had a little problem with the new syntax in python 3 so I
installed python 2.6.4 and guess what, the same error message again!

When I try to run IDLE from cmd this error message is displayed:

hi
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\idlelib\run.py", line 13, in <module>
    import RemoteDebugger
  File "C:\Python26\lib\idlelib\RemoteDebugger.py", line 24, in <module>
    import rpc
  File "C:\Python26\lib\idlelib\rpc.py", line 120, in <module>
    request_queue = Queue.Queue(0)
TypeError: __init__() takes exactly 1 argument (2 given)

Can anyone help?
Thanks in advance

----------
components: IDLE
messages: 94546
nosy: mr.dalba
severity: normal
status: open
title: IDLE Subprocess Startup Error
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7217>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:59:50 2009
From: report at bugs.python.org (ali)
Date: Tue, 27 Oct 2009 07:59:50 +0000
Subject: [issue7217] IDLE Subprocess Startup Error
In-Reply-To: <1256630225.32.0.706380843912.issue7217@psf.upfronthosting.co.za>
Message-ID: <1256630390.89.0.550615504636.issue7217@psf.upfronthosting.co.za>


ali <mr.dalba at gmail.com> added the comment:

I'm using windows vista  x64
I've tried restarting my computer and manually deleting files but didn't
help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7217>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:07:12 2009
From: report at bugs.python.org (Willi Richert)
Date: Tue, 27 Oct 2009 09:07:12 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256634432.9.0.0737998067995.issue7212@psf.upfronthosting.co.za>


Changes by Willi Richert <w.richert at gmx.net>:


Removed file: http://bugs.python.org/file15207/setobject_get.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:08:03 2009
From: report at bugs.python.org (Willi Richert)
Date: Tue, 27 Oct 2009 09:08:03 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256634483.24.0.90590748775.issue7212@psf.upfronthosting.co.za>


Changes by Willi Richert <w.richert at gmx.net>:


Added file: http://bugs.python.org/file15211/setobject_get.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:09:24 2009
From: report at bugs.python.org (Willi Richert)
Date: Tue, 27 Oct 2009 09:09:24 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256634564.23.0.849793769687.issue7212@psf.upfronthosting.co.za>


Willi Richert <w.richert at gmx.net> added the comment:

added tests for get() to test_set.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Tue Oct 27 11:15:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 10:15:53 +0000
Subject: [issue7218] test_site failure under Windows
In-Reply-To: <1256638553.58.0.546981327124.issue7218@psf.upfronthosting.co.za>
Message-ID: <1256638553.58.0.546981327124.issue7218@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This fails quite reliably on Windows buildbots:

======================================================================
FAIL: test_getsitepackages (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_site.py",
line 173, in test_getsitepackages
    self.assertEquals(dirs[1], wanted)
AssertionError: 'xoxo\\lib\\site-packages' != 'xoxo\\Lib\\site-packages'

----------
assignee: tarek
components: Tests
messages: 94549
nosy: pitrou, tarek
priority: high
severity: normal
status: open
title: test_site failure under Windows
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7218>
_______________________________________

From report at bugs.python.org  Tue Oct 27 12:37:46 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Oct 2009 11:37:46 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256643466.51.0.245069288765.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

r75743: Fix cPickle.c to use PyOS_string_to_double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:13:35 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Oct 2009 12:13:35 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256645615.62.0.291336257247.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

r75745: Fix stropmodule.c to use PyOS_string_to_double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:36:03 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Oct 2009 12:36:03 +0000
Subject: [issue7071] Unhelpful error message when a distutils package install
	fails due to a permissions error
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1256646963.81.0.234764713835.issue7071@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This problem showed up when installing a package with IronPython, where
the site-packages folder requires admin privileges to write to (which
*should* be true with CPython Windows but isn't).

If you perform a 'python setup.py install' without admin privileges the
install fails (as it should) but with a very cryptic error message:

C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
creating build
creating build\lib
copying foo.py -> build\lib
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
error: C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py: None

----------
nosy:  -DinoV, brian.curtin, tarek
resolution: accepted -> 
status: closed -> open
title: distutils and IronPython compatibility -> Unhelpful error message when a distutils package install fails due to a permissions error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:36:56 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Oct 2009 12:36:56 +0000
Subject: [issue7071] Unhelpful error message when a distutils package install
	fails due to a permissions error
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1256647016.74.0.347571739368.issue7071@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sorry - meant to create a new issue.

----------
nosy: +tarek
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:37:51 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Oct 2009 12:37:51 +0000
Subject: [issue7219] Unhelpful error message when a distutils package install
	fails due to a permissions error
In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za>
Message-ID: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

This problem showed up when installing a package with IronPython, where
the site-packages folder requires admin privileges to write to (which
*should* be true with CPython Windows but isn't).

If you perform a 'python setup.py install' without admin privileges the
install fails (as it should) but with a very cryptic error message:

C:\compile\test\foo-1.0>"C:\Program Files\IronPython 2.6\ipy.exe"
setup.py install
running install
running build
running build_py
creating build
creating build\lib
copying foo.py -> build\lib
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython
2.6\Lib\site-packages
error: C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py: None

----------
assignee: tarek
keywords: 26backport
messages: 94554
nosy: michael.foord, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Unhelpful error message when a distutils package install fails due to a permissions error
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7219>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:48:18 2009
From: report at bugs.python.org (Martijn Ras)
Date: Tue, 27 Oct 2009 12:48:18 +0000
Subject: [issue7220] python -m no longer executes packages directly
In-Reply-To: <1256647697.94.0.0863288338635.issue7220@psf.upfronthosting.co.za>
Message-ID: <1256647697.94.0.0863288338635.issue7220@psf.upfronthosting.co.za>


New submission from Martijn Ras <Martijn.Ras at GMail.com>:

Heya Folks,

I've just started moving some of my projects from Python 2.5 to Python 2.6.

I used to start some of these packages using python -m <packagename>.

In Python 2.6 this results in the following error:

/usr/bin/python: <packagename> is a package and cannot be directly executed

I got everything running again, by using the following command:

python -m <packagename>.__init__

This strikes me as awkward, since every package should still have the
__init__.py file. Can this be fixed so running python -m <packagename>
will once more be equal to python -m <packagename>.__init__?

Mazzel,

Martijn.

----------
components: None
messages: 94555
nosy: Martijn
severity: normal
status: open
title: python -m no longer executes packages directly
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7220>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:08:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2009 13:08:14 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1256648894.33.0.611100737972.issue7071@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +DinoV, brian.curtin
title: Unhelpful error message when a distutils package install fails due to a permissions error -> distutils and IronPython compatibility

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:09:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 13:09:36 +0000
Subject: [issue7055] Automatic test___all__
In-Reply-To: <1254674711.55.0.0201125202082.issue7055@psf.upfronthosting.co.za>
Message-ID: <1256648976.51.0.720320042893.issue7055@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Finally backported to 2.6 (r75751) and 3.1 (r75752).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7055>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:10:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 13:10:16 +0000
Subject: [issue7084] printing a list releases the GIL carelessly
In-Reply-To: <1255037708.8.0.126059126941.issue7084@psf.upfronthosting.co.za>
Message-ID: <1256649016.48.0.654558605638.issue7084@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Backported to 2.6 in r75750.

----------
resolution: accepted -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7084>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:10:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 13:10:48 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1256649048.02.0.955636402366.issue1722344@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Backported to 2.6 in r75749.

----------
resolution: accepted -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:11:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 13:11:20 +0000
Subject: [issue7194] test_thread is flaky
In-Reply-To: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>
Message-ID: <1256649080.34.0.334129846311.issue7194@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Backported to 2.6 in r75748.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7194>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:12:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 13:12:06 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1256649126.13.0.381517758732.issue5833@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now backported to py3k in r75747.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Tue Oct 27 15:25:52 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Oct 2009 14:25:52 +0000
Subject: [issue7220] python -m no longer executes packages directly
In-Reply-To: <1256647697.94.0.0863288338635.issue7220@psf.upfronthosting.co.za>
Message-ID: <1256653552.79.0.370515431813.issue7220@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This was purposely removed in 2.6 and reworked in 2.7 and 3.1.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7220>
_______________________________________

From report at bugs.python.org  Tue Oct 27 16:35:54 2009
From: report at bugs.python.org (Michael Broghton)
Date: Tue, 27 Oct 2009 15:35:54 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256657754.45.0.786334857923.issue7211@psf.upfronthosting.co.za>


Michael Broghton <mbroughton at advanis.ca> added the comment:

This is against release31-maint, if it matters.

----------
keywords: +patch
Added file: http://bugs.python.org/file15212/kevent.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Tue Oct 27 17:56:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Oct 2009 16:56:57 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1256662617.36.0.369938948471.issue7048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

logb fix applied to release26-maint in r75804.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________

From report at bugs.python.org  Tue Oct 27 18:00:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Oct 2009 17:00:18 +0000
Subject: [issue7078] struct help in the interpreter does not explain about the
	fmt option
In-Reply-To: <1254939027.81.0.0391767098754.issue7078@psf.upfronthosting.co.za>
Message-ID: <1256662818.94.0.286671940161.issue7078@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to release26-maint in r75805.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7078>
_______________________________________

From report at bugs.python.org  Tue Oct 27 18:03:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Oct 2009 17:03:14 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1256662994.11.0.319473796329.issue7048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated release26-maint to new test-suite in r75806.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7048>
_______________________________________

From report at bugs.python.org  Tue Oct 27 18:07:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Oct 2009 17:07:16 +0000
Subject: [issue7051] 'g'/'G' format docs need a little more explanation
In-Reply-To: <1254596355.98.0.43740035661.issue7051@psf.upfronthosting.co.za>
Message-ID: <1256663236.64.0.381216985215.issue7051@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like this was merged to release26-maint by Georg in r75790.  Thanks, 
Georg!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7051>
_______________________________________

From report at bugs.python.org  Tue Oct 27 18:50:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 17:50:31 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1256665831.41.0.414769462806.issue7205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r75818 (trunk), r75819 (2.6), r75820 (py3k), r75821 (3.1). Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Tue Oct 27 19:09:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 18:09:47 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1256666987.07.0.0214144426447.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With r75820:

test_asyncore leaked [153, -152] references, sum=1
test_distutils leaked [0, 2] references, sum=2
test_httpservers leaked [0, 259] references, sum=259
test_pipes leaked [23, 0] references, sum=23
test_threaded_import leaked [1, 0] references, sum=1
test_tokenize leaked [0, 291] references, sum=291
test_urllib leaked [6, 4] references, sum=10
test_uuid leaked [6, 6] references, sum=12
test_zipimport_support leaked [748, 0] references, sum=748
test_zipfile leaked [2, 0] references, sum=2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Tue Oct 27 19:18:32 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Tue, 27 Oct 2009 18:18:32 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256667512.3.0.235949652073.issue7210@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

Yet another patch file....

----------
Added file: http://bugs.python.org/file15213/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Tue Oct 27 19:27:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 18:27:02 +0000
Subject: [issue7221] DispatcherWithSendTests_UsePoll with test_asyncore does
	nothing
In-Reply-To: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za>
Message-ID: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It changes the class variable `usepoll` from its parent to True, but
that variable isn't used anywhere.

----------
assignee: facundobatista
components: Library (Lib), Tests
messages: 94570
nosy: alanmcintyre, facundobatista, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: DispatcherWithSendTests_UsePoll with test_asyncore does nothing
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7221>
_______________________________________

From report at bugs.python.org  Tue Oct 27 19:28:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Oct 2009 18:28:42 +0000
Subject: [issue7099] Decimal.is_normal should return True even for numbers
	with exponent > Emax
In-Reply-To: <1255200323.46.0.445694394995.issue7099@psf.upfronthosting.co.za>
Message-ID: <1256668122.3.0.970067933998.issue7099@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to release26-maint in r75822.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7099>
_______________________________________

From report at bugs.python.org  Tue Oct 27 19:37:05 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Oct 2009 18:37:05 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256668625.28.0.431528190787.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

r75824: Fix ast.c to use PyOS_string_to_double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:00:24 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 27 Oct 2009 19:00:24 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256670024.66.0.251239903906.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This latest patch (14) makes one minor change over the previous -
updates the documentation to include "Availability: Windows" for readlink.

----------
Added file: http://bugs.python.org/file15214/windows symlink draft 14.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:00:30 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 27 Oct 2009 19:00:30 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256670030.37.0.762570666489.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15208/windows symlink draft 13.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:06:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 19:06:35 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1256670395.0.0.323787708732.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

test_asyncore and test_httpservers should now be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:43:23 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Oct 2009 19:43:23 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256672603.27.0.594667506782.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

r75846: Fix marshal.c to use PyOS_string_to_double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:52:54 2009
From: report at bugs.python.org (Florian Mayer)
Date: Tue, 27 Oct 2009 19:52:54 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256673174.38.0.12223733424.issue7203@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

I dare to disagree on this being an adequate fix. Request to reopen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:22:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Oct 2009 20:22:48 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256673174.38.0.12223733424.issue7203@psf.upfronthosting.co.za>
Message-ID: <1afaf6160910271322k50d8ed2bi53631890025feb5a@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/10/27 Florian Mayer <report at bugs.python.org>:
>
> Florian Mayer <flormayer at aim.com> added the comment:
>
> I dare to disagree on this being an adequate fix. Request to reopen.

What would you prefer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:32:59 2009
From: report at bugs.python.org (Rajesh S R)
Date: Tue, 27 Oct 2009 20:32:59 +0000
Subject: [issue5430] imaplib: must not replace LF or CR by CRLF in literals
In-Reply-To: <1236325877.36.0.637700625895.issue5430@psf.upfronthosting.co.za>
Message-ID: <1256675579.62.0.697907378886.issue5430@psf.upfronthosting.co.za>


Rajesh S R <srrajesh1989 at gmail.com> added the comment:

Am quite new here; just searching hard to contribute, would like to
patch this, if I can go ahead.

Don't we need to patch the original imaplib code also?

just remove the line:
self.literal = MapCRLF.sub(CRLF, message)
and have:
self.literal = message
Or am I missing something completely?

----------
nosy: +rajeshsr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5430>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:43:36 2009
From: report at bugs.python.org (Florian Mayer)
Date: Tue, 27 Oct 2009 20:43:36 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256676216.44.0.449760068634.issue7203@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

At least converting

map(None, a, b, ...)

to

map(lambda *xs: xs, a, b, ...)

I can understand if you prefer not to add the itertools.zip_longest
workaround, although that would be the correct translation, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:57:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Oct 2009 20:57:59 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256676216.44.0.449760068634.issue7203@psf.upfronthosting.co.za>
Message-ID: <1afaf6160910271357i35ecf81as57d4378c03f1f170@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/10/27 Florian Mayer <report at bugs.python.org>:
>
> Florian Mayer <flormayer at aim.com> added the comment:
>
> At least converting
>
> map(None, a, b, ...)
>
> to
>
> map(lambda *xs: xs, a, b, ...)

Well, since that's not always correct, we should not translate to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:58:39 2009
From: report at bugs.python.org (Florian Mayer)
Date: Tue, 27 Oct 2009 20:58:39 +0000
Subject: [issue7203] fixer for map(None,
	...) needs to consider multi-argument case
In-Reply-To: <1256493206.19.0.96806885999.issue7203@psf.upfronthosting.co.za>
Message-ID: <1256677119.54.0.107729107964.issue7203@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

When could this possibly be wrong, if I may ask?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7203>
_______________________________________

From report at bugs.python.org  Tue Oct 27 22:24:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 21:24:24 +0000
Subject: [issue7222] thread reaping is imperfect
In-Reply-To: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
Message-ID: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Thread reaping in test_support is imperfect because, even when a thread
has a disappeared from _active and _limbo, the Thread object might still
be hanging somewhere in memory (leaving its last instants). This problem
manifests itself when trying to fix the transient refleaks in
test_socketserver.

One solution I've found is to add a _count() method to the thread
module, which returns the number of running threads from the point of
view of the C extension. When _count() is decremented, we can be sure
the Python method has finished running and the Thread object is not
hanging around.

----------
components: Tests
files: threading_setup.patch
keywords: patch
messages: 94582
nosy: nnorwitz, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: thread reaping is imperfect
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15215/threading_setup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7222>
_______________________________________

From report at bugs.python.org  Tue Oct 27 22:29:57 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 27 Oct 2009 21:29:57 +0000
Subject: [issue7218] test_site failure under Windows
In-Reply-To: <1256638553.58.0.546981327124.issue7218@psf.upfronthosting.co.za>
Message-ID: <1256678997.93.0.529425080349.issue7218@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

fixed in r75871, r75873

thanks

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7218>
_______________________________________

From report at bugs.python.org  Tue Oct 27 23:14:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 22:14:15 +0000
Subject: [issue7222] thread reaping is imperfect
In-Reply-To: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
Message-ID: <1256681655.7.0.869662777998.issue7222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thinking about it, another possibility is to strengthen Thread.join(),
so that it waits for the actual end of the thread, not a small instant
before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7222>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:15:34 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 27 Oct 2009 23:15:34 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1256685334.51.0.510042014247.issue1180@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I've simplified the tests so they just check that [.]pydistutils.cfg is
taken or not taken, depending if the option is used.

I've also made sure the option is just looked in the global options,
because the patch was implying that a command local option with the same
name could work.

Done in r75893 and r75895.

Thanks a lot Paul !

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:25:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 23:25:10 +0000
Subject: [issue7222] thread reaping is imperfect
In-Reply-To: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
Message-ID: <1256685910.17.0.263426555917.issue7222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Forget the last message. While improving Thread.join() can be good, it
still doesn't guarantee that all references have been released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7222>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:30:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 23:30:55 +0000
Subject: [issue7223] Simplify and improve Thread.join()
In-Reply-To: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>
Message-ID: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch improves and simplifies Thread.join() by making sure that the
__bootstrap() method is finished before join() returns. While it does
improve the resource deallocation behaviour, it is still enough for
solving all refleak detection hazards (see #7222).

----------
components: Library (Lib)
files: join.patch
keywords: patch
messages: 94587
nosy: gregory.p.smith, jyasskin, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Simplify and improve Thread.join()
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15216/join.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7223>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:31:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2009 23:31:57 +0000
Subject: [issue7058] Add some test execution environment protection to regrtest
In-Reply-To: <1254697713.91.0.536595090046.issue7058@psf.upfronthosting.co.za>
Message-ID: <1256686317.77.0.801467681471.issue7058@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Enhanced patch applied in r75400, and further enhanced by Nick Coghlan
in r75456, r75457, and r75466.  Ported to py3k by Nick in r75493, with a
little cleanup in r75504.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7058>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:33:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 23:33:34 +0000
Subject: [issue7223] Simplify and improve Thread.join()
In-Reply-To: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>
Message-ID: <1256686414.53.0.751381888924.issue7223@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I meant not enough, of course)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7223>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:35:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Oct 2009 23:35:46 +0000
Subject: [issue7223] Simplify and improve Thread.join()
In-Reply-To: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>
Message-ID: <1256686546.44.0.0993890722351.issue7223@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This patch relies on ref counting behavior, an unfortunate side-effect
for other implementations.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7223>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:36:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 23:36:42 +0000
Subject: [issue7223] Simplify and improve Thread.join()
In-Reply-To: <1256686255.23.0.543755679339.issue7223@psf.upfronthosting.co.za>
Message-ID: <1256686602.1.0.307311978687.issue7223@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed. Let's consider it closed then.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7223>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:41:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Oct 2009 23:41:23 +0000
Subject: [issue7222] thread reaping is imperfect
In-Reply-To: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
Message-ID: <1256686883.07.0.372241296656.issue7222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here's a new patch with tests.

----------
Added file: http://bugs.python.org/file15217/threading_setup2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7222>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:42:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2009 23:42:48 +0000
Subject: [issue7082] Patch for get_filename in email.message when
	content-disposition is missing
In-Reply-To: <1255005833.09.0.380246957911.issue7082@psf.upfronthosting.co.za>
Message-ID: <1256686968.49.0.331635262542.issue7082@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in 2.6 in r75897.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7082>
_______________________________________

From report at bugs.python.org  Wed Oct 28 01:17:22 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Oct 2009 00:17:22 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1256689042.88.0.00841837616318.issue7208@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Just to give credit where credit is due: see #4 here

http://mail.python.org/pipermail/python-dev/2003-December/040579.html

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:05:29 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Oct 2009 01:05:29 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch implements python-ideas proposal to return added or 
existing element from set.add().  See 
http://mail.python.org/pipermail/python-ideas/2009-October/006491.html .

In addition this patch contains a reimplementation of issue1507011 using 
new behavior of set_add.

The two changes are independent an I would submit them separately if I 
was more optimistic that any would be accepted. :-)

This submission is mostly for the benefit of users with applications 
that create huge number of interned strings.  Since the patch saves 8 
bytes for each interned string, such application can see appreciable 
memory savings.

I don't have such application and my tests show no difference between 
patched and stock python.  (For a data point, on start up stock python 
creates about 2,000 interned strings.)

My own motivation for writing this patch was the same as for issue1507011: the code that uses a set to store interned strings is more  
straightforward than code that uses a dict that stores strings twice, 
both as key and value.

----------
components: Interpreter Core
files: set-add.diff
keywords: patch
messages: 94595
nosy: belopolsky
severity: normal
status: open
title: One obvious way to do interning
type: feature request
Added file: http://bugs.python.org/file15218/set-add.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7224>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:07:56 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Oct 2009 01:07:56 +0000
Subject: [issue7045] utf-8 encoding error
In-Reply-To: <1254541613.35.0.521074293953.issue7045@psf.upfronthosting.co.za>
Message-ID: <1256692076.56.0.208923674943.issue7045@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is a duplicate of #3297, and Adam's patch there fixes it.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python interpreter uses Unicode surrogate pairs only before the pyc is created

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7045>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:16:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Oct 2009 01:16:21 +0000
Subject: [issue7225] fwrite() compiler warnings
In-Reply-To: <1256692580.97.0.277746602553.issue7225@psf.upfronthosting.co.za>
Message-ID: <1256692580.97.0.277746602553.issue7225@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

gcc 4.3.2 is currently coughing up warnings like this:

Objects/object.c: In function 'internal_print':                        
                                                                       
                                    
Objects/object.c:301: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result                             
                                          
Objects/object.c:310: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result                             
                                          
Python/marshal.c: In function 'w_string':                              
                              
      
Python/marshal.c:97: warning: ignoring return value of 'fwrite',
declared with attribute warn_unused_result                             
                                           
./Modules/signalmodule.c: In function 'signal_handler':                
                                                                       
                                    
./Modules/signalmodule.c:182: warning: ignoring return value of 'write',
declared with attribute warn_unused_result

----------
components: Build
messages: 94597
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: fwrite() compiler warnings
type: compile error
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7225>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:20:22 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Oct 2009 01:20:22 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1256692822.82.0.986269037672.issue7224@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7224>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:35:18 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 28 Oct 2009 01:35:18 +0000
Subject: [issue7226] IDLE right-clicks don't work on Mac OS 10.5
In-Reply-To: <1256693718.71.0.813168523679.issue7226@psf.upfronthosting.co.za>
Message-ID: <1256693718.71.0.813168523679.issue7226@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I'm sure this has been reported before, by I can't find it. Right button
clicks do nothing on Mac OS X -- they don't go to the line of a
traceback, and in debug mode they don't pop up the breakpoint menu.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 94598
nosy: MLModel, ronaldoussoren
severity: normal
status: open
title: IDLE right-clicks don't work on Mac OS 10.5
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7226>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:56:06 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Oct 2009 01:56:06 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256694966.14.0.898654340475.issue7212@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Any reason you don't want to call set_next from set_get?

I would say

static PyObject *
set_get(PySetObject *so)
{
	register Py_ssize_t pos = 0;
	register setentry *entry;
        if (set_next(so, &pos, &entry)) {
              Py_INCREF(entry->key);
              return entry->key;
        }
        /* set appropriate error */
        return NULL;
}

BTW, what your patch is supposed to do on set().get()?
}

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Wed Oct 28 03:12:25 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Oct 2009 02:12:25 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1256695945.45.0.987536634297.issue5872@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Wed Oct 28 06:27:23 2009
From: report at bugs.python.org (David Lyon)
Date: Wed, 28 Oct 2009 05:27:23 +0000
Subject: [issue7227] Shell Support for installation of Python Packages (.EGG)
In-Reply-To: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
Message-ID: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>


New submission from David Lyon <david.lyon at preisshare.net>:

Under Windows, it would be very handy to have shell support for
installing .EGG packages.

To implement this would require the addition of some registry keys into
the cpython installation to associate the .EGG extension as being a
python package.

Then a new script would be assigned to process the .EGG file if called
from explorer.

This would provide the user with the ability to easily install packages
from web sites such as pypi.

----------
components: Demos and Tools, Installation, Windows
messages: 94600
nosy: djlyon
severity: normal
status: open
title: Shell Support for installation of Python Packages (.EGG)
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7227>
_______________________________________

From report at bugs.python.org  Wed Oct 28 07:13:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 28 Oct 2009 06:13:05 +0000
Subject: [issue7227] Shell Support for installation of Python Packages (.EGG)
In-Reply-To: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
Message-ID: <1256710385.55.0.729283294156.issue7227@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.4, Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7227>
_______________________________________

From report at bugs.python.org  Wed Oct 28 07:49:41 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 06:49:41 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. There is following sentence in Modules/_io/bufferedio.c,

  PyErr_Format(PyExc_IOError,
               "Raw stream returned invalid position %" PY_PRIdOFF,
			 (PY_OFF_T_COMPAT)n);

and PY_PRIdOFF == "lld" when sizeof(off_t) == sizeof(long long).

But it seems that PyErr_Format doesn't support lld as specifier.

I noticed this because
# define PY_OFF_T_COMPAT    long long
caused compile error on my good old VC6. ;-) (VC6 doesn't have it)

----------
messages: 94601
nosy: mark.dickinson, ocean-city
severity: normal
status: open
title: %lld for PyErr_Format (Modules/_io/bufferedio.c)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 07:51:30 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 06:51:30 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256712690.13.0.279348444808.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I believe r75728 and r75879 are related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 07:54:59 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 06:54:59 +0000
Subject: [issue4750] tarfile keeps excessive dir structure in compressed files
In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za>
Message-ID: <1256712899.89.0.966011218077.issue4750@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Lars, is this still accurate ?

----------
nosy: +tarek
versions: +Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4750>
_______________________________________

From report at bugs.python.org  Wed Oct 28 07:55:13 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 06:55:13 +0000
Subject: [issue4750] tarfile keeps excessive dir structure in compressed files
In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za>
Message-ID: <1256712913.42.0.032264369142.issue4750@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components:  -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4750>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:12:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Oct 2009 07:12:14 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256713934.53.0.595244962674.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for reporting this.

Do you know what the right conversion specifier is for print(f)ing 
something of long long type in MSVC?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:20:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Oct 2009 07:20:15 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256714415.34.0.285136404807.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The 'long long' define should have been PY_LONG_LONG.  I don't know what 
the appropriate substitute for "%lld" is, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:21:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 07:21:51 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256714511.24.0.960308046376.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

MSVC6 uses __int64 as 64bit integer, and printf uses "I64" as its specifier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:31:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Oct 2009 07:31:42 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256715102.33.0.0846028448951.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So PY_PRIdOFF should be "I64d"?  Or just "I64"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:37:18 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 07:37:18 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256715438.43.0.494088346915.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oh, I was late. I agree with msg94605.

printf("%I64d\n", 1I64 << 40); /* 1099511627776 */

So if PyErr_Format (actually, PyString_FromFormatV) will support
PY_LONG_LONG, I think we can use same technique as PY_FORMAT_SIZE_T like

#define PY_FORMAT_LONG_LONG "I64" /* On Windows */
#define PY_FORMAT_LONG_LONG "ll"  /* On Unix */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:43:09 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 07:43:09 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256715789.13.0.435394306373.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I was late again...? Hmm, I thought Python tracker told me that somebody
else modified this issue. Anyway, printf can use both "%I64" and "%I64d"
for signed 64bit integer, but should use "%I64u" for unsigned 64bit
integer AFAIK.

But PyErr_Format actually calls PyString_FromFormatV, and it's not
treating %lld. So probably we should modify PyString_FromFormatV.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:48:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Oct 2009 07:48:50 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256716130.99.0.377416567031.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  I'm just going to fix Modules/io/_iomodule.h for now.  But I 
agree that it might make sense to have a PY_FORMAT_OFF_T or 
PY_FORMAT_LONG_LONG in pyport.h, especially if uses of off_t become more 
widespread in the codebase.

I also notice there are some uses of "%zd" in Modules/io that should be 
replaced with PY_FORMAT_SIZE_T.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:54:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Oct 2009 07:54:16 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256716456.02.0.693387663871.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Aargh.  You're right, of course.  PyString_FromFormatV needs to be 
updated, or avoided in this case.

I'll look at this later today.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:59:16 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 28 Oct 2009 07:59:16 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256716756.48.0.358359114657.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry for confusion. I shouldn't have said last 3 lines in msg94601. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Wed Oct 28 09:13:53 2009
From: report at bugs.python.org (Willi Richert)
Date: Wed, 28 Oct 2009 08:13:53 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1256717633.08.0.644715697972.issue7212@psf.upfronthosting.co.za>


Willi Richert <w.richert at gmx.net> added the comment:

No particular reason, besides that it is ripped off of pop().

Your solution (omitting "register") gives the same performance. Looks
cleaner, of course.

The patch tries to provide a clean way of "for x in some_set: break", as
explained above. See the recent python-dev mailing list musings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Wed Oct 28 09:33:00 2009
From: report at bugs.python.org (Patrick Gerken)
Date: Wed, 28 Oct 2009 08:33:00 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1256718780.93.0.990701670993.issue5243@psf.upfronthosting.co.za>


Patrick Gerken <patrick.gerken at computer.org> added the comment:

Hi Tarek,

I think clib stuff is installed in the right python directory and the 
ext install step then just finds them.

To reproduce the issue, run 
the "old" easy_install in a virtualenv.
easy_install ReportLab
It will then fail because of the missing library.

I can also show it during Plone Conference, just look for me in irc.

Thanks,

      Patrick

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Wed Oct 28 09:46:30 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 28 Oct 2009 08:46:30 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256719590.77.0.05495300201.issue7117@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

r75913: Fix _json.c to use PyOS_string_to_double. Change made after
consulting with Bob Ippolito.

This completes the removal of calls to PyOS_ascii_strtod.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:16:38 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Oct 2009 09:16:38 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1256721398.0.0.165182647667.issue7192@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:19:59 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 09:19:59 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1256721599.89.0.283671952199.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This patch will be applied for the part that makes DistributionMetadata
load files.

The other part is waiting for PEP 376.

----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:20:17 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Oct 2009 09:20:17 +0000
Subject: [issue7194] test_thread is flaky
In-Reply-To: <1256322047.39.0.394218490419.issue7194@psf.upfronthosting.co.za>
Message-ID: <1256721617.82.0.892016651317.issue7194@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Duplicate of Issue6186?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7194>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:23:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Oct 2009 09:23:03 +0000
Subject: [issue6186] test_thread occasionally reports unhandled exceptions on
	OS X
In-Reply-To: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>
Message-ID: <1256721783.32.0.942869068389.issue6186@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ned points out that it may be a duplicate of #7194, which has been fixed.
Can you test with the current trunk or 2.6 branch?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6186>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:33:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Oct 2009 09:33:02 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1256722382.93.0.869337336141.issue7224@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A simple way to try and see a difference would be to import lot of modules.

By the way, you shouldn't call it _PySet_Add(), it would cause confusion
with the existing PySet_Add(). _PySet_Intern() would be fine.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7224>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:35:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Oct 2009 09:35:45 +0000
Subject: [issue7227] Shell Support for installation of Python Packages (.EGG)
In-Reply-To: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
Message-ID: <1256722545.56.0.359333757886.issue7227@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils -Demos and Tools
nosy: +tarek
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7227>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:40:51 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Oct 2009 09:40:51 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256722851.32.0.555503074551.issue7175@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

/etc is definitely not the right place to put files for OS X framework 
builds; if necessary, an etc directory could be added under the 
framework version directory as a sibling of bin and lib.  It's also very 
un-OS X like to be putting things into ~/.python and ~/.local 
directories; the usual place would be in somewhere ~/Library, possibly 
~/Library/Application Support/Python or ~/Library/Frameworks.  Keep in 
mind that it's much more likely on OS X to not only have muitiple 
versions of Python installed but also more than one instance of the 
*same* version, for instance, on 10.6, an Apple-supplied 2.6.2 and a 
python.org 2.6.4.  Some thought should be given to locations for the 
files for Unix-style (non-framework) builds.

(Adding Ronald.)

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:44:12 2009
From: report at bugs.python.org (Tomas Kubes)
Date: Wed, 28 Oct 2009 09:44:12 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>


New submission from Tomas Kubes <mr_napik at centrum.cz>:

Hello,

it is not obvious that the time.daylight data item reports nonzero
values even when DST is currently not being used (ie. in winter) but the
active timezone has DST defined for some other parts of the year.

Current manual entry can be misleadingly interpreted that time.daylight
acts as a current DST idicator (which it does not).

Suggested FIX: Add a sentence:
This value does not idicate that DST is currently active, but rather
describes that current timezone can have DST. Use localtime() dst flag
to determine if DST applies to the given time.


Tomas

----------
assignee: georg.brandl
components: Documentation
messages: 94621
nosy: georg.brandl, napik
severity: normal
status: open
title: Manual entry for time.daylight can be misleading
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:46:18 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 28 Oct 2009 09:46:18 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256722851.32.0.555503074551.issue7175@psf.upfronthosting.co.za>
Message-ID: <4AE812E7.1000806@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ned Deily wrote:
> 
> Ned Deily <nad at acm.org> added the comment:
> 
> /etc is definitely not the right place to put files for OS X framework 
> builds; if necessary, an etc directory could be added under the 
> framework version directory as a sibling of bin and lib.  It's also very 
> un-OS X like to be putting things into ~/.python and ~/.local 
> directories; the usual place would be in somewhere ~/Library, possibly 
> ~/Library/Application Support/Python or ~/Library/Frameworks.  Keep in 
> mind that it's much more likely on OS X to not only have muitiple 
> versions of Python installed but also more than one instance of the 
> *same* version, for instance, on 10.6, an Apple-supplied 2.6.2 and a 
> python.org 2.6.4.  Some thought should be given to locations for the 
> files for Unix-style (non-framework) builds.
> 
> (Adding Ronald.)

I think there is a misunderstanding here: we're trying to find
places where distutils would look by default, not where it
would write files.

AFAIK, there is general agreement that when writing files,
Python should use the ~/.local/pythonX.X/ directory.

OTOH, searching for config files that the user creates and
puts in place is another story. Python and distutils only
need to be able to find these and the idea is to use platform
specific standard search paths for this, so that the user
can place those config files into places that feel right on
each platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Wed Oct 28 11:24:20 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Oct 2009 10:24:20 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256725460.11.0.519386035906.issue7175@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I don't think there's a misunderstanding.  By "putting", I meant "reading" 
or "writing".  IMO, /etc is not the place on OS X to be looking for 
python-related configuration files, certainly not for framework installs.  
Likewise for ~/.python and ~/.local.  Unfortunately, the latter is already 
out in the field; that was a step in the wrong direction for OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Wed Oct 28 11:30:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 10:30:02 +0000
Subject: [issue7227] Shell Support for installation of Python Packages (.EGG)
In-Reply-To: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
Message-ID: <1256725802.83.0.801329702649.issue7227@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The .egg format and easy_install are not part of by Distutils.

You can try to propose your .egg shell support to Pip, Distribute 0.6.x
or Setuptools 0.6x projects.

----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7227>
_______________________________________

From report at bugs.python.org  Wed Oct 28 11:30:09 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 10:30:09 +0000
Subject: [issue7227] Shell Support for installation of Python Packages (.EGG)
In-Reply-To: <1256707642.83.0.00840383945529.issue7227@psf.upfronthosting.co.za>
Message-ID: <1256725809.3.0.0122291757547.issue7227@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7227>
_______________________________________

From report at bugs.python.org  Wed Oct 28 12:15:34 2009
From: report at bugs.python.org (Eric BREHAULT)
Date: Wed, 28 Oct 2009 11:15:34 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1256728534.0.0.0484356479499.issue2698@psf.upfronthosting.co.za>


Eric BREHAULT <ebrehault at gmail.com> added the comment:

Hello,

I get the same error with Python 2.6.3 (and gcc 3.4.5):
E:\downloads\pycairo-1.8.8>python setup.py build --compiler=mingw32
cairo >= 1.8.8 detected
creating pycairo.pc
creating src/config.h
running build
running build_ext
building 'cairo._cairo' extension
error: Unable to find vcvarsall.bat

wasn't it supposed to be fixed (since 2.6.2) ?

Thanks,

Eric

----------
nosy: +ebrehault

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:09:50 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 12:09:50 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1256731790.3.0.363941713903.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

A regression occured in 2.6.3 on the compiler option. This is fixed in
2.6.4, you should upgrade your system in order to see it fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:09:52 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Oct 2009 12:09:52 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1256731792.91.0.821911353336.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

A regression occured in 2.6.3 on the compiler option. This is fixed in
2.6.4, you should upgrade your system in order to see it fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:06:07 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Wed, 28 Oct 2009 14:06:07 +0000
Subject: [issue7230] test_hotshot fails on solaris
In-Reply-To: <1256738767.32.0.166548042812.issue7230@psf.upfronthosting.co.za>
Message-ID: <1256738767.32.0.166548042812.issue7230@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

On sparc/solaris 5.8, test_hotshot fails:

csernazs at localhost:/tmp/python2.6$ LD_LIBRARY_PATH=/tmp/python2.6
./python -E -tt ./Lib/test/regrtest.py -v -l test_hotshot

test_hotshot
test_addinfo (test.test_hotshot.HotShotTestCase) ... ok
test_bad_sys_path (test.test_hotshot.HotShotTestCase) ... ok
test_line_numbers (test.test_hotshot.HotShotTestCase) ... ok
test_logreader_eof_error (test.test_hotshot.HotShotTestCase) ... FAIL
test_start_stop (test.test_hotshot.HotShotTestCase) ... ok

======================================================================
FAIL: test_logreader_eof_error (test.test_hotshot.HotShotTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/python2.6/Lib/test/test_hotshot.py", line 130, in
test_logreader_eof_error
    self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
AssertionError: (<type 'exceptions.IOError'>, <type
'exceptions.EOFError'>) not raised

----------------------------------------------------------------------
Ran 5 tests in 0.037s

FAILED (failures=1)
test test_hotshot failed -- Traceback (most recent call last):
  File "/tmp/python2.6/Lib/test/test_hotshot.py", line 130, in
test_logreader_eof_error
    self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
AssertionError: (<type 'exceptions.IOError'>, <type
'exceptions.EOFError'>) not raised

1 test failed:
    test_hotshot

>From test_hotshot.py:

    def test_logreader_eof_error(self):
        self.assertRaises((IOError, EOFError), _hotshot.logreader, ".")
        gc.collect()

If I run python command-line interpreter, it doesn't raise exception:

>>> import _hotshot
>>> _hotshot.logreader(".")
<_hotshot.LogReaderType object at 0x3f260>
>>> 

On intel/linux, this test passes.

----------
components: Library (Lib)
messages: 94628
nosy: csernazs
severity: normal
status: open
title: test_hotshot fails on solaris
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7230>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:19:36 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Oct 2009 14:19:36 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1256739576.94.0.551711885528.issue7169@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Since the issue exists in 2.6 and is only currently fixed on trunk and
beyond, shouldn't the 6511 fix make it's way backwards into 2.6.x?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:37:05 2009
From: report at bugs.python.org (skelker)
Date: Wed, 28 Oct 2009 14:37:05 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1256739576.94.0.551711885528.issue7169@psf.upfronthosting.co.za>
Message-ID: <52C333133934CA4585938535BE63885C16F4AA7D@EX02.dtn.com>


skelker <steve.kelker at dtn.com> added the comment:

That would be great.  Perhaps that should be discussed in 6511.  I'll make a note there.

Steve Kelker
(952)882-4381 (or x4381)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:38:34 2009
From: report at bugs.python.org (skelker)
Date: Wed, 28 Oct 2009 14:38:34 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1256740714.9.0.925190370827.issue6511@psf.upfronthosting.co.za>


skelker <steve.kelker at dtn.com> added the comment:

Is this going to make its way into a 2.6 release?

----------
nosy: +skelker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________

From report at bugs.python.org  Wed Oct 28 17:06:29 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Oct 2009 16:06:29 +0000
Subject: [issue7224] One obvious way to do interning
In-Reply-To: <1256691929.12.0.04518648136.issue7224@psf.upfronthosting.co.za>
Message-ID: <1256745989.76.0.179750367541.issue7224@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree, _PySet_Add name can be improved upon, but I don't want to paint 
this particular bikeshed until it is clearer what if anything will be done 
with this idea.  If we add PySet_Intern API, then it would be natural to 
expose it as set.intern rather than changing how set.add works.  On the 
other hand, if set.add grows a return value, then it would make sense to 
eventually change PySet_Add to conform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7224>
_______________________________________

From report at bugs.python.org  Wed Oct 28 17:59:12 2009
From: report at bugs.python.org (sorin)
Date: Wed, 28 Oct 2009 16:59:12 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

I observed that Windows installer is able to add only the Python
installation folder to the path. 

In addition to this it should add the Scrips folder because many python
tools are installing scripts inside it, scripts that the user cannot us
unless he add this directory to the path. 

This is very annoying because if you modify the PATH you need to
logout/login in order to be able to use the new PATH value.

----------
components: Installation
messages: 94633
nosy: sorin
severity: normal
status: open
title: Windows installer does not add \Scripts folder to the path
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7231>
_______________________________________

From report at bugs.python.org  Wed Oct 28 18:58:46 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Oct 2009 17:58:46 +0000
Subject: [issue6834] use different mechanism for pythonw on osx: universal
	builds always run 64-bit on OS X 10.6
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1256752726.95.0.867862636202.issue6834@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

For people searching the bug tracker, I've modified the title of the 
issue to make it clearer that there is a problem here on OS X 10.6 Snow 
Leopard with multiple architecture builds.

As Ronald mentions above, the effect of using the pythonw "launcher" on 
10.6 as it currently stands is to always prefer x86_64 (64-bit) over 
i386 (32-bit) when both are available.  arch -i386 only forces the 
launcher to run as 32-bit; the execv runs the interpreter in 64-bit mode 
(if available).  To get a multi-arch (32/64) interpreter to run in 32-
bit, one workaround is to arch -i386 directly to the interpreter binary 
in the framework app bundle, typically:
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/C
ontents/MacOS/Python
But then, presumably, the GUI functionality no longer works.

A more robust workaround would be to build a 32-bit-only Python (but 
ensure that -arch is forced on the build - see Issue7184).

----------
nosy: +ned.deily
title: use different mechanism for pythonw on osx -> use different mechanism for pythonw on osx: universal builds always run 64-bit on OS X 10.6
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:02:25 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Wed, 28 Oct 2009 18:02:25 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1256752945.55.0.466009061816.issue7169@psf.upfronthosting.co.za>


Ryan Leslie <rylesny at gmail.com> added the comment:

Yes, I think this fix should have been included in the 2.6 branch. I
subscribed Amaury to look into that when I last updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:09:04 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Oct 2009 18:09:04 +0000
Subject: [issue6834] use different mechanism for pythonw on osx: universal
	builds always run 64-bit on OS X 10.6
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1256753344.93.0.482425788238.issue6834@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:25:04 2009
From: report at bugs.python.org (Robin)
Date: Wed, 28 Oct 2009 18:25:04 +0000
Subject: [issue6834] use different mechanism for pythonw on osx: universal
	builds always run 64-bit on OS X 10.6
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1256754304.53.0.90183843377.issue6834@psf.upfronthosting.co.za>


Changes by Robin <robince at gmail.com>:


----------
nosy: +robince

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Wed Oct 28 20:19:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2009 19:19:37 +0000
Subject: [issue7169] zipfile leaves a file handle open if file is zero size
In-Reply-To: <1255959228.67.0.513383976461.issue7169@psf.upfronthosting.co.za>
Message-ID: <1256757577.93.0.264526504603.issue7169@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The 2.6 branch was frozen except for critical issues during the release
process for 2.6.3 and then 2.6.4.  Now that 2.6.4 is out, the bug fix
can be backported.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7169>
_______________________________________

From report at bugs.python.org  Wed Oct 28 20:19:52 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Wed, 28 Oct 2009 19:19:52 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256757592.42.0.312019861695.issue7175@psf.upfronthosting.co.za>


Changes by Frank Wierzbicki <fwierzbicki at gmail.com>:


----------
nosy: +fwierzbicki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Wed Oct 28 21:11:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 28 Oct 2009 20:11:45 +0000
Subject: [issue7175] unify pydistutils.cfg and distutils.cfg and use .local
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1256760705.25.0.157505639491.issue7175@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with Ned that neither ~/.local nor /etc are a good fit for OSX, 
sadly enough I wasn't paying attention when ~/.local was added as python 
already had a per-user directory on OSX: ~/Library/Python.

The common unix directories are often not a good pick for good OSX 
citizens, even if OSX is build on Unix.

The OSX filesystem structure should be described somewhere below 
<http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/
BPFileSystem/BPFileSystem.html#//apple_ref/doc/uid/10000185>, although I 
haven't found a clear explanation yet.

Technically configuration files should be stored in /Library/Preferences 
(system wide) or ~/Library/Preferences (per user), but I'd say 
practicality beats purity here and I'd store configuration in 
/Library/Python/etc or ~/Library/Python/etc. 

BTW. I haven't read most of the discussion yet, I'll probably have more 
to add when I do.  What I did notice was a proposal to store the 
distutils cfg file in ~/.local/lib/pythonX.Y/site-
packages/distutils.cfg. IMHO that way to hidden and an unexpected 
location for storing configuration files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Wed Oct 28 21:16:57 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 28 Oct 2009 20:16:57 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1256761017.01.0.714405206435.issue6834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: I'm planning to use the attached version of pythonw, or a slightly 
updated one, for 2.7 and 3.2. This version will not be used for 2.6.5 or 
3.1.2 due to backward compatibility constraints.

I will look into the OSX launching issues though, it was my intention that 
universal builds had a way to select a 32-bit or 64-bit python but that 
code may be broken.

----------
title: use different mechanism for pythonw on osx: universal builds always run 64-bit on OS X 10.6 -> use different mechanism for pythonw on osx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Wed Oct 28 22:02:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Oct 2009 21:02:28 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256763748.68.0.94272115228.issue7210@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please just add your test case to the bottom of the trunk...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Wed Oct 28 22:57:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Oct 2009 21:57:03 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1256767023.63.0.545081374949.issue3297@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
dependencies: +UnicodeEncodeError - I can't even see license

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Wed Oct 28 22:59:56 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Oct 2009 21:59:56 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1256767196.99.0.497601198694.issue3297@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Committed Adam's patch in r75928.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Wed Oct 28 23:33:59 2009
From: report at bugs.python.org (Tim Hatch)
Date: Wed, 28 Oct 2009 22:33:59 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1256769239.25.0.17819317721.issue6906@psf.upfronthosting.co.za>


Tim Hatch <tim at timhatch.com> added the comment:

I'm running the exact same version as Gabriel (on Windows 7, 32 bit)
from the python.org installer, and have the same behavior as Micha?. 
Checking FixTk.py it appears that on Vista and above, it calls the Win32
API GetFinalPathNameByHandleW to expand symbolic links, but this is a -W
function, not a -A so it deals with unicode.

The blame shows this function was added in response to #3881

For my system, the paths are all lower ascii so changing the end of
convert_path to return str(s) works.  I don't know anything about
filesystem encodings on Windows to do a more correct conversion.

----------
nosy: +thatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________

From report at bugs.python.org  Thu Oct 29 00:29:12 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 28 Oct 2009 23:29:12 +0000
Subject: [issue7199] Doc: Logging level order seems inconsistent
In-Reply-To: <1256425131.73.0.619062754292.issue7199@psf.upfronthosting.co.za>
Message-ID: <1256772552.49.0.249288099655.issue7199@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk, release26-maint, py3k.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7199>
_______________________________________

From report at bugs.python.org  Thu Oct 29 01:59:14 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 29 Oct 2009 00:59:14 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256777954.67.0.784516467694.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This patch (15) implements ntpath.samefile, which corrects the
regression in test_shutil.

By my tests, this corrects all regressions caused by this patch except
for those in test_posixpath.py previously mentioned. I believe these
failing tests are due to the fact that posixpath tests are inappropriate
on the Windows platform.

I propose we integrate this patch so it can have time to get feedback
from the community.

----------
Added file: http://bugs.python.org/file15219/windows symlink draft 15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Oct 29 02:00:32 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 29 Oct 2009 01:00:32 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1256778032.88.0.831098744388.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15214/windows symlink draft 14.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Oct 29 03:07:35 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 29 Oct 2009 02:07:35 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1256782055.18.0.70819045968.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
for MinGW users. The following C program is using the Python C API to
import the testpyd extension generated by testpyd.py. When compiled with
MinGW, the program fails with "ImportError: DLL load failed:..." if the
PYD extension is compiled with MSVC9 and the patch is applied. The
program works if 1) it is compiled with MSVC9, or 2) the testpyd
extension is build without the patch, or 3) the files
Microsoft.VC90.CRT.manifest and msvcr90.dll are placed next to the
executable and the manifest is also embedded into the executable (e.g.
using mt.exe).


/* Import the testpyd.pyd module. */
#include <Python.h>
int main(void) {
    Py_Initialize();
    { 
        PyObject *p = PyImport_ImportModule("testpyd"); 
    }
    Py_Finalize();
    return 0;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Oct 29 08:29:40 2009
From: report at bugs.python.org (Jaime Buelta)
Date: Thu, 29 Oct 2009 07:29:40 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>


New submission from Jaime Buelta <jaime.buelta at gmail.com>:

Currently, the TarFile is not supporting the 'with' statement, which I
think it should for coherence with other file classes. 

I've already created a patch including it for consideration.

----------
components: Library (Lib)
files: tarfileWithSupport.patch
keywords: patch
messages: 94645
nosy: jaime.buelta
severity: normal
status: open
title: Support of 'with' statement fo TarFile class
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15220/tarfileWithSupport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Thu Oct 29 09:10:54 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 29 Oct 2009 08:10:54 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1256803854.36.0.797480097933.issue7232@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Please clean up the patch, and I take another look at it.

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Thu Oct 29 09:24:40 2009
From: report at bugs.python.org (Jaime Buelta)
Date: Thu, 29 Oct 2009 08:24:40 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1256804680.09.0.945664029416.issue7232@psf.upfronthosting.co.za>


Jaime Buelta <jaime.buelta at gmail.com> added the comment:

I've cleaned the patch, I don't now why Eclipse added a lot of garbage,
sorry.

----------
Added file: http://bugs.python.org/file15221/tarfileWithSupportv2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Thu Oct 29 09:52:05 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 29 Oct 2009 08:52:05 +0000
Subject: [issue4750] tarfile keeps excessive dir structure in compressed files
In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za>
Message-ID: <1256806325.61.0.659598112266.issue4750@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

The latest patch (4750.gzip.basename.fix.diff) cannot be used the way it
is. The problem is that it uses the name attribute to store the basename
with the .gz extension stripped. This breaks compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4750>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:21:03 2009
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Oct 2009 09:21:03 +0000
Subject: [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

I got two issues with the all-important function rotate():

1. It should probably convert an integer argument:

>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 4
>>> Decimal("1000000000").rotate(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 3411, in rotate
    ans = self._check_nans(other, context)
  File "/usr/lib/python2.7/decimal.py", line 738, in _check_nans
    other_is_nan = other._isnan()


2. When the coefficient size is greater than prec, the most significant
digits should be truncated before rotating:

>>> c.prec = 4
>>> Decimal("1000000000").rotate(Decimal(1))
Decimal('1')


The result should be 0 (checked against decNumber).

----------
messages: 94649
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: two rotate() issues
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:23:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 09:23:59 +0000
Subject: [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256808239.49.0.79138315106.issue7233@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agreed on both counts.  I'll take a look.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:43:50 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 29 Oct 2009 09:43:50 +0000
Subject: [issue4750] tarfile keeps excessive dir structure in compressed files
In-Reply-To: <1230297599.68.0.395552641842.issue4750@psf.upfronthosting.co.za>
Message-ID: <1256809430.75.0.983613299782.issue4750@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I fixed it in r75935 and r75937.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4750>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:58:00 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 29 Oct 2009 09:58:00 +0000
Subject: [issue5500] tarfile: path problem in arcname under windows
In-Reply-To: <1237304162.51.0.555320282686.issue5500@psf.upfronthosting.co.za>
Message-ID: <1256810280.42.0.126810444641.issue5500@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I suppose this issue is related to issue4750 which I have just closed.
If not, please reopen this issue.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5500>
_______________________________________

From report at bugs.python.org  Thu Oct 29 11:01:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 10:01:48 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256810508.24.0.620154166884.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've rolled back all the changes I made trying to fix these format 
arguments;  the rollback is in r75939 (trunk), r75941 (py3k) and r75942 
(release31-maint).  Next time I'll think a bit harder, get a code 
review, and make sure that the code gets tested on Windows before it 
goes in.

I agree that what's needed here is %lld and %llu support in PyErr_Format 
and PyString_FromFormat(V);  this seems like a useful thing to add in 
any case.

ocean-city:  you don't happen to have a patch available, do you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Thu Oct 29 11:07:54 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 29 Oct 2009 10:07:54 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256810874.67.0.236188387569.issue1628484@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Perhaps we can get some movement regarding this problem again, as it
also applies to other platforms that require special gcc options for the
compiler and linker.

A common case where such settings were needed is Mac OS X - in the case
of building universal binaries. Since this was too tedious to get right,
Python 2.5 introduced new configure options to simplify this. In Python
2.4, you had to configure Python using these  configure options to get a
universal build:

BASECFLAGS="-arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk" LDFLAGS="-arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk"

... and that shows part of the problem with the Python configure/make
system: it simply doesn't follow the standards used in other OSS
software of passing through CFLAGS et al. to all subsequent compiler and
linker calls.

In order to get compiler options passed through, you have to set BASECFLAGS.

For linker options, you may have some luck with using LDFLAGS, but not
always, since e.g. the configure script may sometimes add LDFLAGS to
LDSHARED (e.g. on Mac OS X using the universal binary options), which
then results in the options to show up twice on the linker line. Using
LDSHARED directly instead then helps.

As a result, simply adding CFLAGS and LDFLAGS to a few more targets
definitions in the Makefile will likely cause more trouble on other
platforms and in other situations.

Overall, the whole configure/Makefile system for defining compiler and
linker options has gotten somewhat messy over the years and much of it
is not documented (at least I'm not aware of any such documentation
apart from the ticket and checkin messages related to the various changes).

I think a first step in the right direction would be to make sure that
LDSHARED never automagically gets additional values from LDFLAGS. Then
we could at least add LDFLAGS to all targets that use LDSHARED as linker
command for shared libs.

As second step, I think that the CFLAGS environment variable passed to
configure should be made to init the BASECFLAGS Makefile variable, since
that's what the user would expect (if he knew how the system works).

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Thu Oct 29 11:17:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 10:17:44 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256811464.0.0.279296273707.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The next job is to deprecate PyOS_ascii_atof and PyOS_ascii_strtod, I 
think.  I'll get to work on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Thu Oct 29 11:46:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 10:46:09 +0000
Subject: [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256813169.34.0.791068883752.issue7233@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The shift function should also accept an integer 2nd argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________

From report at bugs.python.org  Thu Oct 29 12:10:47 2009
From: report at bugs.python.org (David Fraser)
Date: Thu, 29 Oct 2009 11:10:47 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1256814647.76.0.79179365878.issue3871@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


----------
nosy: +davidfraser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Oct 29 12:34:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 11:34:08 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1256816048.75.0.521051944087.issue5872@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch is huge.

Some things:
- you should provide an example of using the new API. Your description
is not very, well, descriptive :)
- "all PyTypeObjects must now be *pointers* rather than static
instances": is it mandatory, or did you add this out of "purity"? It
would be nice if we could minimize disruption (that is, provide the new
API as a feature, but not force ourselves and other people to rewrite
huge chunks of code)
- same for the private declaration of PyTypeObject: is it really
necessary to hide it from outside code?

Lastly, since your patch is not ready for consumption, I would advocate
creating a branch somewhere (on the SVN sandbox if you have access
rights, or in a separate e.g. bitbucket repository by cloning the
existing Mercurial mirror).

----------
nosy: +nnorwitz, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:04:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 12:04:11 +0000
Subject: [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256817851.74.0.829941128871.issue7233@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There were a number of Decimal methods that failed to accept an integer 
second argument.  I've fixed that in r75944.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:11:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 12:11:49 +0000
Subject: [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256818309.54.0.992649014394.issue7233@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And the shift and rotate bugs for large arguments are fixed in r75945.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:16:32 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 29 Oct 2009 12:16:32 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1256782055.18.0.70819045968.issue4120@psf.upfronthosting.co.za>
Message-ID: <4AE9879C.1050606@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Christoph Gohlke wrote:
> 
> Christoph Gohlke <cgohlke at uci.edu> added the comment:
> 
> Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
> for MinGW users. The following C program is using the Python C API to
> import the testpyd extension generated by testpyd.py. When compiled with
> MinGW, the program fails with "ImportError: DLL load failed:..." if the
> PYD extension is compiled with MSVC9 and the patch is applied. The
> program works if 1) it is compiled with MSVC9, or 2) the testpyd
> extension is build without the patch, or 3) the files
> Microsoft.VC90.CRT.manifest and msvcr90.dll are placed next to the
> executable and the manifest is also embedded into the executable (e.g.
> using mt.exe).
> 
> 
> /* Import the testpyd.pyd module. */
> #include <Python.h>
> int main(void) {
>     Py_Initialize();
>     { 
>         PyObject *p = PyImport_ImportModule("testpyd"); 
>     }
>     Py_Finalize();
>     return 0;
> }

I'm not sure whether this is related to the problem in question.
Does MinGW also embed a manifest in the generated executable ?

If it doesn't, then this is more likely a problem with how
MinGW works per default, than with Python or distutils.

The fact that the above does work without the patch applied
suggests that MinGW does not embed the manifest in the executable
(since the Windows linker then uses the one from the PYD file).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:25:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Oct 2009 12:25:33 +0000
Subject: [issue7233] decimal.py: two rotate() issues
In-Reply-To: <1256808063.4.0.75529666771.issue7233@psf.upfronthosting.co.za>
Message-ID: <1256819133.24.0.405124511654.issue7233@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged (along with a test numbering fix in extra.decTest) in r75946 
(release26-maint), r75947 (py3k) and r75948 (release31-maint).

Thanks for the report!

----------
components: +Library (Lib)
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7233>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:09:29 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:09:29 +0000
Subject: [issue7234] Complete your registration to Python tracker --
	keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7
In-Reply-To: <200910292109153190232@yahoo.com.cn>
Message-ID: <200910292109153190232@yahoo.com.cn>

__________________________________________________
?????????????????????????????
http://cn.mail.yahoo.com
-------------- next part --------------
???<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.5880" name=GENERATOR>
<STYLE>@font-face {
	font-family: ??????;
}
@font-face {
	font-family: Verdana;
}
@font-face {
	font-family: @??????;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
UNKNOWN {
	FONT-SIZE: 10pt
}
BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana color=#000080 size=2>
<DIV>the</DIV>
<DIV>reply's&nbsp;additional&nbsp;"Re:"&nbsp;is&nbsp;ok</DIV></FONT></DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#c0c0c0 size=2>2009-10-29 </FONT></DIV><FONT 
face=Verdana color=#000080 size=2>
<HR style="WIDTH: 100px" align=left color=#b5c4df SIZE=1>
</FONT>
<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>?????????</SPAN> </FONT></DIV>
<HR color=#b5c4df SIZE=1>

<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> Python tracker 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>???????????????</STRONG> 2009-10-29&nbsp; 21:07:41 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> lpp1985 </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> Complete your registration 
to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7 </FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV>
<DIV><FONT face=Verdana size=2>
<DIV>To&nbsp;complete&nbsp;your&nbsp;registration&nbsp;of&nbsp;the&nbsp;user&nbsp;"kaka"&nbsp;with</DIV>
<DIV>Python&nbsp;tracker,&nbsp;please&nbsp;do&nbsp;one&nbsp;of&nbsp;the&nbsp;following:</DIV>
<DIV></DIV>
<DIV>-&nbsp;send&nbsp;a&nbsp;reply&nbsp;to&nbsp;report at bugs.python.org&nbsp;and&nbsp;maintain&nbsp;the&nbsp;subject&nbsp;line&nbsp;as&nbsp;is&nbsp;(the</DIV>
<DIV>reply's&nbsp;additional&nbsp;"Re:"&nbsp;is&nbsp;ok),</DIV>
<DIV></DIV>
<DIV>-&nbsp;or&nbsp;visit&nbsp;the&nbsp;following&nbsp;URL:</DIV>
<DIV></DIV>
<DIV>http://bugs.python.org/?@action=confrego&amp;otk=RVZuTYMju0LifnIK60WPnidSrLQIHXI7</DIV>
<DIV></DIV></FONT></DIV></BODY></HTML>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20091029/91acb57c/attachment-0001.obj>

From report at bugs.python.org  Thu Oct 29 14:15:50 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:15:50 +0000
Subject: [issue7235] IO libary have some error
In-Reply-To: <1256822150.5.0.9072293037.issue7235@psf.upfronthosting.co.za>
Message-ID: <1256822150.5.0.9072293037.issue7235@psf.upfronthosting.co.za>


New submission from lpp1985 <lpp1985 at yahoo.com.cn>:

The parameter 'newline' in os.open() functiion in the condition of 
input could ought to be set to any character.But if I set anythin 
else '','\n','\r\n',and '\r',there will be a error raise.This is maybe 
a bug in this libary.

----------
components: Library (Lib)
messages: 94663
nosy: kaka
severity: normal
status: open
title: IO libary have some error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7235>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:18:13 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Oct 2009 13:18:13 +0000
Subject: [issue7234] Complete your registration to Python tracker --
	keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7
In-Reply-To: <200910292109153190232@yahoo.com.cn>
Message-ID: <1256822293.57.0.534247973082.issue7234@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7234>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:18:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 13:18:28 +0000
Subject: [issue7235] IO libary have some error
In-Reply-To: <1256822150.5.0.9072293037.issue7235@psf.upfronthosting.co.za>
Message-ID: <1256822308.95.0.324341451327.issue7235@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's by design. If you want to split on arbitrary characters, use the
split() method on string and bytes objects.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7235>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:18:29 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:18:29 +0000
Subject: [issue7236] the reply's additional "Re:" is ok
In-Reply-To: <200910292118222109920@yahoo.com.cn>
Message-ID: <200910292118222109920@yahoo.com.cn>

__________________________________________________
?????????????????????????????
http://cn.mail.yahoo.com
-------------- next part --------------
???<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.5880" name=GENERATOR>
<STYLE>@font-face {
	font-family: ??????;
}
@font-face {
	font-family: Verdana;
}
@font-face {
	font-family: @??????;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
UNKNOWN {
	FONT-SIZE: 10pt
}
BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#c0c0c0 size=2>2009-10-29 </FONT></DIV><FONT 
face=Verdana color=#000080 size=2>
<HR style="WIDTH: 100px" align=left color=#b5c4df SIZE=1>
</FONT>
<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>?????????</SPAN> </FONT></DIV>
<HR color=#b5c4df SIZE=1>

<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> Python tracker 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>???????????????</STRONG> 2009-10-29&nbsp; 21:07:41 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> lpp1985 </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> Complete your registration 
to Python tracker -- keyRVZuTYMju0LifnIK60WPnidSrLQIHXI7 </FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV>
<DIV><FONT face=Verdana size=2>
<DIV>To&nbsp;complete&nbsp;your&nbsp;registration&nbsp;of&nbsp;the&nbsp;user&nbsp;"kaka"&nbsp;with</DIV>
<DIV>Python&nbsp;tracker,&nbsp;please&nbsp;do&nbsp;one&nbsp;of&nbsp;the&nbsp;following:</DIV>
<DIV></DIV>
<DIV>-&nbsp;send&nbsp;a&nbsp;reply&nbsp;to&nbsp;report at bugs.python.org&nbsp;and&nbsp;maintain&nbsp;the&nbsp;subject&nbsp;line&nbsp;as&nbsp;is&nbsp;(the</DIV>
<DIV>reply's&nbsp;additional&nbsp;"Re:"&nbsp;is&nbsp;ok),</DIV>
<DIV></DIV>
<DIV>-&nbsp;or&nbsp;visit&nbsp;the&nbsp;following&nbsp;URL:</DIV>
<DIV></DIV>
<DIV>http://bugs.python.org/?@action=confrego&amp;otk=RVZuTYMju0LifnIK60WPnidSrLQIHXI7</DIV>
<DIV></DIV></FONT></DIV></BODY></HTML>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20091029/4cea5e3d/attachment.obj>

From report at bugs.python.org  Thu Oct 29 14:19:58 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Oct 2009 13:19:58 +0000
Subject: [issue7236] the reply's additional "Re:" is ok
In-Reply-To: <200910292118222109920@yahoo.com.cn>
Message-ID: <1256822398.49.0.848331884432.issue7236@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7236>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:29:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 13:29:43 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256822983.89.0.678272373714.issue7211@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

According to man pages on the Web, the kevent structure is:

     struct kevent {
	     uintptr_t ident;	     /* identifier for this event */
	     short     filter;	     /* filter for event */
	     u_short   flags;	     /* action flags for kqueue */
	     u_int     fflags;	     /* filter flag value */
	     intptr_t  data;	     /* filter data value */
	     void      *udata;	     /* opaque user data identifier */
     };

So the `ident` field is indeed an uintptr_t.
However the patch is slightly wrong IMO:

- you should not blindly use `long long`. Python already defines a
"Py_uintptr_t" type. If you need more information you should conditional
compilation such as in (for the off_t type)
http://svn.python.org/view/python/trunk/Modules/_io/_iomodule.h?view=markup

- in tests, you should use sys.maxsize (which gives you the max value of
a ssize_t integer) rather than choosing based on platform.architecture():

>>> sys.maxsize
9223372036854775807
>>> 2**64*1
18446744073709551616L
>>> sys.maxsize*2 + 1
18446744073709551615L


PS : a patch against trunk or py3k is preferred, but in this case it
would probably apply cleanly anyway

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:31:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 13:31:23 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256823083.12.0.757050334407.issue7211@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently Roundup borked the URL. Let's try another one (or look into
Modules/_io/_iomodule.h): 
http://code.python.org/hg/trunk/file/b9bc35171668/Modules/_io/_iomodule.h#l88

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Thu Oct 29 14:38:20 2009
From: report at bugs.python.org (lpp1985)
Date: Thu, 29 Oct 2009 13:38:20 +0000
Subject: [issue7235] IO libary have some error
In-Reply-To: <1256822150.5.0.9072293037.issue7235@psf.upfronthosting.co.za>
Message-ID: <200910292138126319812@yahoo.com.cn>


lpp1985 <lpp1985 at yahoo.com.cn> added the comment:

But sometimes the content of file in too large to put into memory,So I need a tool to solve this problem.Just only modify a subclass in Io could solve this problem.To me ,it is difficult,but simple to your team!

2009-10-29 

????????? 

???????????? Antoine Pitrou 
??????????????? 2009-10-29  21:18:31 
???????????? lpp1985 
????????? 
????????? [issue7235] IO libary have some error 

Antoine Pitrou <pitrou at free.fr> added the comment:
It's by design. If you want to split on arbitrary characters, use the
split() method on string and bytes objects.
----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7235>
_______________________________________

----------
Added file: http://bugs.python.org/file15226/unnamed
Added file: http://bugs.python.org/file15227/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7235>
_______________________________________
-------------- next part --------------
???<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.5880" name=GENERATOR>
<STYLE>@font-face {
	font-family: ??????;
}
@font-face {
	font-family: Verdana;
}
@font-face {
	font-family: @??????;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
	TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
UNKNOWN {
	FONT-SIZE: 10pt
}
BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana color=#000080 size=2>But sometimes the content of file 
in too large to put into memory,So I need a tool to solve this problem.Just only 
modify a subclass in Io could solve this problem.To me ,it is difficult,but 
simple to your team!</FONT></DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#c0c0c0 size=2>2009-10-29 </FONT></DIV><FONT 
face=Verdana color=#000080 size=2>
<HR style="WIDTH: 100px" align=left color=#b5c4df SIZE=1>
</FONT>
<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>?????????</SPAN> </FONT></DIV>
<HR color=#b5c4df SIZE=1>

<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> Antoine Pitrou 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>???????????????</STRONG> 2009-10-29&nbsp; 21:18:31 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>????????????</STRONG> lpp1985 </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>?????????</STRONG> [issue7235] IO libary have 
some error </FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV>
<DIV><FONT face=Verdana size=2>
<DIV></DIV>
<DIV>Antoine&nbsp;Pitrou&nbsp;&lt;pitrou at free.fr&gt;&nbsp;added&nbsp;the&nbsp;comment:</DIV>
<DIV></DIV>
<DIV>It's&nbsp;by&nbsp;design.&nbsp;If&nbsp;you&nbsp;want&nbsp;to&nbsp;split&nbsp;on&nbsp;arbitrary&nbsp;characters,&nbsp;use&nbsp;the</DIV>
<DIV>split()&nbsp;method&nbsp;on&nbsp;string&nbsp;and&nbsp;bytes&nbsp;objects.</DIV>
<DIV></DIV>
<DIV>----------</DIV>
<DIV>nosy:&nbsp;+pitrou</DIV>
<DIV>resolution:&nbsp;&nbsp;-&gt;&nbsp;invalid</DIV>
<DIV>status:&nbsp;open&nbsp;-&gt;&nbsp;closed</DIV>
<DIV></DIV>
<DIV>_______________________________________</DIV>
<DIV>Python&nbsp;tracker&nbsp;&lt;report at bugs.python.org&gt;</DIV>
<DIV>&lt;http://bugs.python.org/issue7235&gt;</DIV>
<DIV>_______________________________________</DIV></FONT></DIV></BODY></HTML>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20091029/183f4ffd/attachment.obj>

From report at bugs.python.org  Thu Oct 29 15:40:21 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 29 Oct 2009 14:40:21 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1256827221.9.0.491306260116.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

My last comment was merely reporting that this patch can break MinGW
based build processes. It did surprise some developers that their
programs embedding matplotlib, which is now build with the MSVC9 patch,
stopped working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Oct 29 15:53:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 14:53:13 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1256827993.09.0.403679736015.issue4970@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Prelude has had the same problem with signal 32:
https://dev.prelude-ids.com/issues/show/133
According to their research, it is due to the linuxthreads
implementation of the pthread API.

To know which threads implementation your glibc is using, you can run
"getconf GNU_LIBPTHREAD_VERSION" (on a modern system, it should print
something like "NPTL 2.9").

(of course, the question is, since the signal is used by linuxthreads,
why doesn't it get caught instead of killing the process?)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Thu Oct 29 15:59:07 2009
From: report at bugs.python.org (Michael Broghton)
Date: Thu, 29 Oct 2009 14:59:07 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256828347.4.0.0333053539419.issue7211@psf.upfronthosting.co.za>


Michael Broghton <mbroughton at advanis.ca> added the comment:

Antoine, thanks for the tips and the example. I have updated the patch.

I checked and this does apply cleanly to py3k.

----------
Added file: http://bugs.python.org/file15228/kevent.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:34:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 15:34:57 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1256830497.2.0.253830813989.issue4970@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sridhar, Neal, I would advocate disabling (commenting out)
test_closerange in Lib/test/test_os.py and see what happens.

That's the one really dirty test in test_os, it might close a file
handle linuxthreads is relying on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:44:56 2009
From: report at bugs.python.org (Koen van de Sande)
Date: Thu, 29 Oct 2009 15:44:56 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1256831096.67.0.302567180144.issue4120@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

The MinGW breakage probably comes from the same "issue" as encountered
in http://bugs.python.org/issue4120#msg80908 and #msg80909: the main
application, which embeds Matplotlib, does not have a manifest for the
MSVCR9 runtimes? That's a problem which should be addressed by adding a
manifest in the main application (and manifests can also be separate
files called app.exe.manifest if you do not want to embed it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:47:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 15:47:43 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1256831263.17.0.976976106864.issue4970@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Forget the last comment, test_closerange is fine...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:56:27 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Oct 2009 15:56:27 +0000
Subject: [issue7237] Syntax error with not
In-Reply-To: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
Message-ID: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

lambertdw$ p3
Python 3.1.1 (r311:74480, Oct  2 2009, 12:29:57) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> not 23
False
>>> not(23&1)
False
>>> 1+not(23&1)
  File "<stdin>", line 1
    1+not(23&1)
        ^
SyntaxError: invalid syntax
>>>

----------
components: Interpreter Core
messages: 94675
nosy: LambertDW
severity: normal
status: open
title: Syntax error with not
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7237>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:58:56 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Oct 2009 15:58:56 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1256831936.66.0.674187158042.issue7211@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch (http://bugs.python.org/file15228/kevent.patch) works for me
under OS X 10.5.8 Intel.

All tests pass, except test_telnetlib which fails intermittently with
and without the patch.

Python 3.2a0 (py3k:75951, Oct 29 2009, 11:38:58) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7211>
_______________________________________

From report at bugs.python.org  Thu Oct 29 17:54:43 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Oct 2009 16:54:43 +0000
Subject: [issue7237] Syntax error with not
In-Reply-To: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
Message-ID: <1256835283.29.0.0280033078147.issue7237@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

problem also exists in 2.6.
It's a, in my humble opinion, release blocker.

----------
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7237>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:08:01 2009
From: report at bugs.python.org (acummings)
Date: Thu, 29 Oct 2009 17:08:01 +0000
Subject: [issue5582] Incorrect DST transition
In-Reply-To: <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>
Message-ID: <1256836081.01.0.906757150913.issue5582@psf.upfronthosting.co.za>


acummings <acummings at aperiogroup.com> added the comment:

The same thing happens with the autumn transition.  Windows knows the 
transition has changed, but python does not seem to know that:

The following interactive session was run on Oct 29th, at 10:02 (Windows 
clock reported 10:02):

>>> july1 = datetime(2009, 7, 1)
>>> jan1 = datetime(2009, 1,1)
>>> oct30 = datetime(2009, 10, 30)
>>> time.localtime(time.mktime(july1.timetuple()))
(2009, 7, 1, 0, 0, 0, 2, 182, 1)
>>> time.localtime(time.mktime(jan1.timetuple()))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(oct30.timetuple()))
(2009, 10, 30, 0, 0, 0, 4, 303, 0)
>>> time.localtime(time.mktime(datetime.now().timetuple()))
(2009, 10, 29, 9, 2, 38, 3, 302, 0)

Again, the 9th element of the timetuple is 1 for July 1st, 0 for Jan 
1st, and **0** for Oct 30th and Oct 29th. Also, the time reported by 
datetime.now() was 9:02, one hour behind.

----------
title: Incorrect DST transition on Windows -> Incorrect DST transition

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5582>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:11:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Oct 2009 17:11:09 +0000
Subject: [issue7237] Syntax error with not
In-Reply-To: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
Message-ID: <1256836269.36.0.932012096437.issue7237@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

>>> 1+not
  File "<stdin>", line 1
    1+not
        ^
SyntaxError: invalid syntax
>>> 1+(not(23&1))
1

It's been this way since 2.4 at least, probably earlier.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7237>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:13:15 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Oct 2009 17:13:15 +0000
Subject: [issue7237] Syntax error with not
In-Reply-To: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
Message-ID: <1256836395.51.0.355759091915.issue7237@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not sure what release it would be blocking. The oldest version I
have on hand is 2.4, and it's a problem there. If it hasn't caused an
actual problem in that long, then I don't see it as all that critical.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7237>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:16:58 2009
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 29 Oct 2009 17:16:58 +0000
Subject: [issue7238] frame.f_lineno doesn't get updated after local trace
	function assigned to it
In-Reply-To: <1256836618.71.0.0275056583438.issue7238@psf.upfronthosting.co.za>
Message-ID: <1256836618.71.0.0275056583438.issue7238@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

As you can see, when a local trace function sets f_lineno, f_lineno 
doesn't get updated on subsequent lines. Otherwise it works fine.
$ python tracer_testcase.py                                                                                                                      
12
12
12

13
14
15

The reference manual (for python 2.6) states the following: "f_lineno is 
the current line number of the frame ? writing to this from within a 
trace function jumps to the given line (only for the bottom-most frame). 
A debugger can implement a Jump command (aka Set Next Statement) by 
writing to f_lineno.". This is contradictory with the shown results, 
because apparently it doesn't always represent the current line number.

----------
components: Interpreter Core
files: tracer_testcase.py
messages: 94681
nosy: eggy
severity: normal
status: open
title: frame.f_lineno doesn't get updated after local trace function assigned to it
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15229/tracer_testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7238>
_______________________________________

From report at bugs.python.org  Thu Oct 29 20:07:30 2009
From: report at bugs.python.org (MN)
Date: Thu, 29 Oct 2009 19:07:30 +0000
Subject: [issue7239] Error when running a code
In-Reply-To: <1256843250.15.0.0510719700355.issue7239@psf.upfronthosting.co.za>
Message-ID: <1256843250.15.0.0510719700355.issue7239@psf.upfronthosting.co.za>


New submission from MN <mauronilson at gmail.com>:

Process:         Python [12980]
Path:           
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
Identifier:      org.python.python
Version:         2.6.4 (2.6.4)
Code Type:       X86 (Native)
Parent Process:  Python [12768]

Date/Time:       2009-10-29 18:54:32.502 +0000
OS Version:      Mac OS X 10.6.1 (10B504)
Report Version:  6

Interval Since Last Report:          67916 sec
Crashes Since Last Report:           8
Per-App Interval Since Last Report:  10 sec
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      2FD60074-C28B-48E1-AB01-5A5B2E3B28D3

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  4

Application Specific Information:
abort() called

Thread 0:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x948df822 semaphore_wait_signal_trap
+ 10
1   libSystem.B.dylib             	0x9490d3d8 _pthread_cond_wait + 1089
2   libSystem.B.dylib             	0x9495670f pthread_cond_wait + 48
3   org.python.python             	0x000f6a1c PyThread_acquire_lock + 172
4   org.python.python             	0x000fb473 lock_PyThread_acquire_lock
+ 83
5   org.python.python             	0x000c0165 PyEval_EvalFrameEx + 19429
6   org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
7   org.python.python             	0x000c034c PyEval_EvalFrameEx + 19916
8   org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
9   org.python.python             	0x000c034c PyEval_EvalFrameEx + 19916
10  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
11  org.python.python             	0x000c034c PyEval_EvalFrameEx + 19916
12  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
13  org.python.python             	0x0003f746 function_call + 166
14  org.python.python             	0x0000ed35 PyObject_Call + 85
15  org.python.python             	0x00020b36 instancemethod_call + 422
16  org.python.python             	0x0000ed35 PyObject_Call + 85
17  org.python.python             	0x000ba5be
PyEval_CallObjectWithKeywords + 78
18  org.python.python             	0x00023a02 PyInstance_New + 114
19  org.python.python             	0x0000ed35 PyObject_Call + 85
20  org.python.python             	0x000beab7 PyEval_EvalFrameEx + 13623
21  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
22  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
23  org.python.python             	0x000c0a25 PyEval_EvalFrameEx + 21669
24  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
25  org.python.python             	0x0003f746 function_call + 166
26  org.python.python             	0x0000ed35 PyObject_Call + 85
27  org.python.python             	0x000bdf2c PyEval_EvalFrameEx + 10668
28  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
29  org.python.python             	0x000c034c PyEval_EvalFrameEx + 19916
30  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
31  org.python.python             	0x000c23f7 PyEval_EvalCode + 87
32  org.python.python             	0x000e888f PyRun_StringFlags + 287
33  org.python.python             	0x000e898e PyRun_SimpleStringFlags + 78
34  org.python.python             	0x000f929e Py_Main + 1486
35  org.python.python             	0x00001f82 0x1000 + 3970
36  org.python.python             	0x00001ea9 0x1000 + 3753

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x9490603a kevent + 10
1   libSystem.B.dylib             	0x94906768 _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x94905bf9 _dispatch_queue_invoke + 183
3   libSystem.B.dylib             	0x9490598a _dispatch_worker_thread2 + 234
4   libSystem.B.dylib             	0x94905401 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x94905246 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             	0x94905092 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x94905628 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x94905246 start_wqthread + 30

Thread 3:
0   libSystem.B.dylib             	0x948df822 semaphore_wait_signal_trap
+ 10
1   libSystem.B.dylib             	0x9490d3d8 _pthread_cond_wait + 1089
2   libSystem.B.dylib             	0x9495670f pthread_cond_wait + 48
3   org.python.python             	0x000f6a1c PyThread_acquire_lock + 172
4   org.python.python             	0x000ba2e3 PyEval_RestoreThread + 67
5   select.so                     	0x007dd6ea select_select + 490
6   org.python.python             	0x000c0165 PyEval_EvalFrameEx + 19429
7   org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
8   org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
9   org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
10  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
11  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
12  org.python.python             	0x0003f746 function_call + 166
13  org.python.python             	0x0000ed35 PyObject_Call + 85
14  org.python.python             	0x00020b36 instancemethod_call + 422
15  org.python.python             	0x0000ed35 PyObject_Call + 85
16  org.python.python             	0x000beab7 PyEval_EvalFrameEx + 13623
17  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
18  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
19  org.python.python             	0x0003f746 function_call + 166
20  org.python.python             	0x0000ed35 PyObject_Call + 85
21  org.python.python             	0x00020b36 instancemethod_call + 422
22  org.python.python             	0x0000ed35 PyObject_Call + 85
23  org.python.python             	0x000beab7 PyEval_EvalFrameEx + 13623
24  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
25  org.python.python             	0x0003f746 function_call + 166
26  org.python.python             	0x0000ed35 PyObject_Call + 85
27  org.python.python             	0x00020b36 instancemethod_call + 422
28  org.python.python             	0x0000ed35 PyObject_Call + 85
29  org.python.python             	0x00075897 slot_tp_init + 87
30  org.python.python             	0x000742c0 type_call + 176
31  org.python.python             	0x0000ed35 PyObject_Call + 85
32  org.python.python             	0x000beab7 PyEval_EvalFrameEx + 13623
33  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
34  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
35  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
36  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
37  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
38  org.python.python             	0x0003f746 function_call + 166
39  org.python.python             	0x0000ed35 PyObject_Call + 85
40  org.python.python             	0x000bdf2c PyEval_EvalFrameEx + 10668
41  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
42  org.python.python             	0x000c0ae6 PyEval_EvalFrameEx + 21862
43  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
44  org.python.python             	0x0003f746 function_call + 166
45  org.python.python             	0x0000ed35 PyObject_Call + 85
46  org.python.python             	0x00020b36 instancemethod_call + 422
47  org.python.python             	0x0000ed35 PyObject_Call + 85
48  org.python.python             	0x000ba5be
PyEval_CallObjectWithKeywords + 78
49  org.python.python             	0x000fbaef t_bootstrap + 63
50  libSystem.B.dylib             	0x9490cf39 _pthread_start + 345
51  libSystem.B.dylib             	0x9490cdbe thread_start + 34

Thread 4 Crashed:
0   libSystem.B.dylib             	0x9494cc2e __semwait_signal_nocancel + 10
1   libSystem.B.dylib             	0x9494cb12
nanosleep$NOCANCEL$UNIX2003 + 166
2   libSystem.B.dylib             	0x949c85a6 usleep$NOCANCEL$UNIX2003 + 61
3   libSystem.B.dylib             	0x949e9c5c abort + 105
4   com.tcltk.tcllibrary          	0x0065d4a3 Tcl_Panic + 0
5   com.tcltk.tcllibrary          	0x0065d4be Tcl_Panic + 27
6   com.tcltk.tklibrary           	0x00753215 Tk_MacOSXSetupTkNotifier + 120
7   com.tcltk.tklibrary           	0x007496f0 TkpInit + 45
8   com.tcltk.tklibrary           	0x006dd67a Initialize + 2173
9   _tkinter.so                   	0x005fa83c Tcl_AppInit + 140
10  _tkinter.so                   	0x005f8738 Tkinter_Create + 968
11  org.python.python             	0x000c0165 PyEval_EvalFrameEx + 19429
12  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
13  org.python.python             	0x0003f746 function_call + 166
14  org.python.python             	0x0000ed35 PyObject_Call + 85
15  org.python.python             	0x00020b36 instancemethod_call + 422
16  org.python.python             	0x0000ed35 PyObject_Call + 85
17  org.python.python             	0x000ba5be
PyEval_CallObjectWithKeywords + 78
18  org.python.python             	0x00023a02 PyInstance_New + 114
19  org.python.python             	0x0000ed35 PyObject_Call + 85
20  org.python.python             	0x000beab7 PyEval_EvalFrameEx + 13623
21  org.python.python             	0x000c22dd PyEval_EvalCodeEx + 2109
22  org.python.python             	0x0003f746 function_call + 166
23  org.python.python             	0x0000ed35 PyObject_Call + 85
24  org.python.python             	0x000ba5be
PyEval_CallObjectWithKeywords + 78
25  org.python.python             	0x000fbaef t_bootstrap + 63
26  libSystem.B.dylib             	0x9490cf39 _pthread_start + 345
27  libSystem.B.dylib             	0x9490cdbe thread_start + 34

Thread 4 crashed with X86 Thread State (32-bit):
  eax: 0x0000003c  ebx: 0x9494ca79  ecx: 0xb02055fc  edx: 0x9494cc2e
  edi: 0x2f317e35  esi: 0xb0205658  ebp: 0xb0205638  esp: 0xb02055fc
   ss: 0x0000001f  efl: 0x00000247  eip: 0x9494cc2e   cs: 0x00000007
   ds: 0x0000001f   es: 0x0000001f   fs: 0x0000001f   gs: 0x00000037
  cr2: 0xb0207c58

Binary Images:
    0x1000 -     0x1ff5 +org.python.python 2.6.4 (2.6.4)
<4037E992-5FF7-89F8-C547-77DF78B19D35>
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
    0x5000 -   0x130fe3 +org.python.python 2.6.4, (c) 2004-2008 Python
Software Foundation. (2.6.4) <74126CA0-A482-4EDB-B195-CE276F49DA9E>
/Library/Frameworks/Python.framework/Versions/2.6/Python
  0x1f5000 -   0x1f6fff +time.so ??? (???)
<CE38317A-468D-F3F1-D021-0360AD0CAF4A>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/time.so
  0x3c0000 -   0x3c7fff +_socket.so ??? (???)
<C1B22680-310E-C1E5-8BFE-4A7CB8E454ED>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_socket.so
  0x3d0000 -   0x3d3ff7 +_ssl.so ??? (???)
<4CB670AF-33F3-41BD-769C-F28FC27BB467>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_ssl.so
  0x3d9000 -   0x3fffff  libssl.0.9.7.dylib ??? (???)
<8BF98B2F-0F55-40CA-C082-43C76707BD24> /usr/lib/libssl.0.9.7.dylib
  0x40e000 -   0x4c3fe7  libcrypto.0.9.7.dylib ??? (???)
<4917E4F2-817F-5AC4-3FBE-54BC96360448> /usr/lib/libcrypto.0.9.7.dylib
  0x509000 -   0x50aff9 +cStringIO.so ??? (???)
<4C6A1DF3-FC4E-3E99-EB62-D9F4B455D23C>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cStringIO.so
  0x50f000 -   0x50fffc +_functools.so ??? (???)
<F84F4FEF-3FB0-C7D5-DB89-E8419D70D30A>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_functools.so
  0x513000 -   0x516ff3 +_collections.so ??? (???)
<78B59DC9-8C1C-FD7F-1CA1-AAA38F6F70B3>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_collections.so
  0x51c000 -   0x51ffff +operator.so ??? (???)
<06B2B012-039B-F139-56A8-AEB0E9B94056>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/operator.so
  0x526000 -   0x52affe +itertools.so ??? (???)
<59707961-1A72-58D1-CAFA-C6A533F0FC87>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so
  0x533000 -   0x533ff5 +_bisect.so ??? (???)
<B0BA9213-688E-F914-30A0-E0E57FC01B4E>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_bisect.so
  0x537000 -   0x538ff9 +_heapq.so ??? (???)
<D6155E99-1427-0DA4-80AC-B3E898C66AED>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_heapq.so
  0x5f4000 -   0x5faff5 +_tkinter.so ??? (???)
<F69893FD-D21D-24B9-2D85-979EBF155695>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
  0x601000 -   0x692fe7  com.tcltk.tcllibrary 8.4.19 (8.4.19)
<6FF5C975-96BA-3370-AD5D-AAE625BE5D9A>
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl
  0x6b0000 -   0x77afe7  com.tcltk.tklibrary 8.4.19 (8.4.19)
<4F15559E-41DD-54A7-81DC-216B5B743401>
/System/Library/Frameworks/Tk.framework/Versions/8.4/Tk
  0x7d2000 -   0x7d5ffc +strop.so ??? (???)
<E2AD56A2-4C71-DDA9-D714-553270C062EE>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/strop.so
  0x7db000 -   0x7ddfff +select.so ??? (???)
<06E5920F-2F6A-B301-E6AA-A22A9F9F2A9D>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/select.so
  0x7e3000 -   0x7e6ff7 +_struct.so ??? (???)
<1D6CFA30-A56B-C2F2-42AD-AF363C54B793>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_struct.so
  0x7ed000 -   0x7effff +math.so ??? (???)
<06E35D7B-2246-9698-B12B-CC112597523B>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/math.so
  0x7f5000 -   0x7fafff +binascii.so ??? (???)
<F0A84DF3-E036-B7CA-C5CF-B7AE66F412CF>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so
 0x1340000 -  0x134efff +cPickle.so ??? (???)
<440E0C46-62CF-5C05-15AF-17F94C922F9D>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cPickle.so
 0x13f6000 -  0x13f7fff +_random.so ??? (???)
<D19D89FC-872B-6A7B-F936-886275F9D8ED>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_random.so
 0x13fb000 -  0x13fcff0 +fcntl.so ??? (???)
<21B2B1EE-58CF-E74F-B145-30EF50FB8D64>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/fcntl.so
 0x1400000 -  0x1401ffe +_locale.so ??? (???)
<D7A81337-6283-5088-4E05-CE9DE1EA845A>
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_locale.so
0x8fe00000 - 0x8fe4162b  dyld 132.1 (???)
<211AF0DD-42D9-79C8-BB6A-1F4BEEF4B4AB> /usr/lib/dyld
0x90114000 - 0x9011dff7  com.apple.DiskArbitration 2.3 (2.3)
<E9C40767-DA6A-6CCB-8B00-2D5706753000>
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9011e000 - 0x90164ff7  libauto.dylib ??? (???)
<FAB17F30-A28B-E33D-6E21-C7119C9C83ED> /usr/lib/libauto.dylib
0x90165000 - 0x901a8ff7  com.apple.NavigationServices 3.5.3 (181)
<28CDD978-030E-7D4A-5334-874A8EBE6C29>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x90717000 - 0x9077bffb  com.apple.htmlrendering 72 (1.1.4)
<4D451A35-FAB6-1288-71F6-F24A4B6E2371>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x907c6000 - 0x907d3ff7  com.apple.NetFS 3.2 (3.2)
<E6FD80B0-0238-0C42-A3EC-EBDEC107A1C3>
/System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x907d4000 - 0x907deff7  libCSync.A.dylib ??? (???)
<A05BB12D-CD51-DE43-323B-3A3E99A3EED5>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x907df000 - 0x907e0ff7  com.apple.TrustEvaluationAgent 1.0 (1)
<71E2DA16-83EC-6056-FFEE-862A04B5599F>
/System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x90838000 - 0x908d5ff3  com.apple.LaunchServices 360.3 (360.3)
<C8590D53-E46A-F58A-7CF2-03A8159D8569>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x90cf5000 - 0x90cf5ff7  com.apple.Accelerate.vecLib 3.5 (vecLib 3.5)
<3E039E14-2A15-56CC-0074-EE59F9FBB913>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x90cf6000 - 0x90d07ff7  com.apple.LangAnalysis 1.6.5 (1.6.5)
<E77440D0-76EE-EB4C-3D00-9EDE417F13CF>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x90d08000 - 0x90d77ff7  libvMisc.dylib ??? (???)
<59243A8C-2B98-3E71-8032-884D4853E79F>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x90de7000 - 0x90e30fe7  libTIFF.dylib ??? (???)
<6EF87001-6FB4-1405-C588-F6D8042D3534>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x90e31000 - 0x90eeafe7  libsqlite3.dylib ??? (???)
<16CEF8E8-8C9A-94CD-EF5D-05477844C005> /usr/lib/libsqlite3.dylib
0x90eeb000 - 0x90f3bfe7  libGLU.dylib ??? (???)
<55A69DCE-1237-341E-F239-CDFE1F5B19BB>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x90f3f000 - 0x90f5dff7  com.apple.CoreVideo 1.6.0 (43.0)
<3A853574-DD9E-08D8-FD2C-6221B55C3E08>
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x90fa7000 - 0x913dcff7  libLAPACK.dylib ??? (???)
<5E2D2283-57DE-9A49-1DB0-CD027FEFA6C2>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x913dd000 - 0x913e1ff7  libGFXShared.dylib ??? (???)
<ED62E870-E219-C873-88AA-9CE08108F811>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x913e2000 - 0x913e4ff7  libRadiance.dylib ??? (???)
<0E03CF64-0931-7B9A-F617-4387B809D6D8>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x91426000 - 0x91527fe7  libxml2.2.dylib ??? (???)
<C242A74D-280A-90C3-3F79-891624AA45D2> /usr/lib/libxml2.2.dylib
0x91688000 - 0x916e8fe7  com.apple.CoreText 3.0.0 (???)
<8F4FCAE2-8E6F-F0DE-A6AA-15D0228B7F13>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x916e9000 - 0x916f9ff7  libsasl2.2.dylib ??? (???)
<C8744EA3-0AB7-CD03-E639-C4F2B910BE5D> /usr/lib/libsasl2.2.dylib
0x916fa000 - 0x916fdff7  libCoreVMClient.dylib ??? (???)
<16BB2178-B32D-E57E-F1E4-D177F7754232>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x916fe000 - 0x91703ff7  com.apple.OpenDirectory 10.6 (10.6)
<92582807-E8F3-3DD9-EB42-4195CFB754A1>
/System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x91717000 - 0x91809ff7  libcrypto.0.9.8.dylib ??? (???)
<792B8722-3091-5E9F-E25F-67499CFE0599> /usr/lib/libcrypto.0.9.8.dylib
0x92802000 - 0x92c18ff7  libBLAS.dylib ??? (???)
<C4FB303A-DB4D-F9E8-181C-129585E59603>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x92f14000 - 0x92f18ff7  libGIF.dylib ??? (???)
<51848EBF-27D4-0F85-C22A-D1AE10D328F3>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x92f19000 - 0x92f31ff7  com.apple.CFOpenDirectory 10.6 (10.6)
<1537FB4F-C112-5D12-1E5D-3B1002A4038F>
/System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x92f51000 - 0x9302eff7  com.apple.vImage 4.0 (4.0)
<64597E4B-F144-DBB3-F428-0EC3D9A1219E>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x930ce000 - 0x930cfff7  com.apple.audio.units.AudioUnit 1.6 (1.6)
<68180B96-381C-A09D-5576-606A134FD953>
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x930d0000 - 0x931aafff  com.apple.DesktopServices 1.5.1 (1.5.1)
<D9C18268-699B-A996-1035-4EA3695F4074>
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x93b8b000 - 0x93c23fe7  edu.mit.Kerberos 6.5.8 (6.5.8)
<BA9BD282-FF56-3BFD-E78C-7DBE73B48480>
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x93c24000 - 0x93ceefef  com.apple.CoreServices.OSServices 352 (352)
<D9F21CA4-EED0-705F-8F3C-F1322D114B52>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x93fc7000 - 0x94237ffb  com.apple.Foundation 6.6 (751)
<A61B645E-1A15-5BCA-3043-C8AB85C6AD30>
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x94238000 - 0x94238ff7  com.apple.CoreServices 44 (44)
<AC35D112-5FB9-9C8C-6189-5F5945072375>
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x94239000 - 0x9423bff7  com.apple.securityhi 4.0 (36638)
<962C66FB-5BE9-634E-0810-036CB340C059>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x9437c000 - 0x943c0fe7  com.apple.Metadata 10.6.0 (507.1)
<CBD1B22B-5F10-C784-03A2-35106B97DF3F>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x943c1000 - 0x9442bfe7  libstdc++.6.dylib ??? (???)
<411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib
0x945fe000 - 0x94780fe7  libicucore.A.dylib ??? (???)
<FBB66376-CBA9-8149-A1AA-10AB8578C3B3> /usr/lib/libicucore.A.dylib
0x9488f000 - 0x948c2ff7  com.apple.AE 496 (496)
<B638FDD4-7322-F0E4-ACEB-777D8A1399E1>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x948c3000 - 0x948deff7  libPng.dylib ??? (???)
<38DD4AA1-0643-85A0-F2F5-EE9269729975>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x948df000 - 0x94a83feb  libSystem.B.dylib ??? (???)
<E58B649F-FFDC-AB09-2028-8B706BEF7C0F> /usr/lib/libSystem.B.dylib
0x94a86000 - 0x94aa6fe7  libresolv.9.dylib ??? (???)
<A48921CB-3FA7-3071-AF9C-2D86FB493A3A> /usr/lib/libresolv.9.dylib
0x94aa7000 - 0x94ae9fe7  libvDSP.dylib ??? (???)
<8F8FFFB3-81E3-2969-5688-D5B0979182E6>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x952d0000 - 0x953f9fe7  com.apple.audio.toolbox.AudioToolbox 1.6 (1.6)
<62BEEBE6-68FC-4A48-91CF-39DA2BD793F1>
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x95523000 - 0x9552afff  com.apple.print.framework.Print 6.0 (237)
<7A06B15C-B835-096E-7D96-C2FE8F0D21E1>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x9552b000 - 0x956a2fef  com.apple.CoreFoundation 6.6 (550)
<193E33D6-2E92-3452-773B-60A1A9CCC573>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x956c1000 - 0x95712ff7  com.apple.HIServices 1.8.0 (???)
<B8EC13DB-A81A-91BF-8C82-66E840C64C91>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x95752000 - 0x957f9fe7  com.apple.CFNetwork 454.4 (454.4)
<7C563385-9893-3B48-8607-5BC81DA2C4CF>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x95805000 - 0x95b24fe7  com.apple.CoreServices.CarbonCore 859.1 (859.1)
<2E72AF56-4BE6-294A-7372-19C360688B8B>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x95b25000 - 0x95bd4fef  com.apple.ColorSync 4.6.0 (4.6.0)
<66ABAE86-B0EC-D641-913D-08ACA965F9FA>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x95bd5000 - 0x95c09ff7  libcups.2.dylib ??? (???)
<9078BA07-DEE1-6597-D15D-7BE3A20CB5A0> /usr/lib/libcups.2.dylib
0x95c0a000 - 0x95c8afeb  com.apple.SearchKit 1.3.0 (1.3.0)
<9E18AEA5-F4B4-8BE5-EEA9-818FC4F46FD9>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x95ce5000 - 0x95d3fff7  com.apple.framework.IOKit 2.0 (???)
<7618DDEC-2E3B-9C6E-FDC9-15169E24B4FB>
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x95d40000 - 0x95de8ff7  com.apple.QD 3.31 (???)
<40FCAC85-4E4F-2290-90D4-F66D550ADFDC>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x95de9000 - 0x95de9ff7  com.apple.vecLib 3.5 (vecLib 3.5)
<17BEEF92-DF30-CD52-FD65-0B7B43B93617>
/System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x95e6a000 - 0x95e70fff  com.apple.CommonPanels 1.2.4 (91)
<2438AF5D-067B-B9FD-1248-2C9987F360BA>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x95f33000 - 0x95f47ffb  com.apple.speech.synthesis.framework 3.10.35
(3.10.35) <57DD5458-4F24-DA7D-0927-C3321A65D743>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x95f48000 - 0x95f52fe7  com.apple.audio.SoundManager 3.9.3 (3.9.3)
<5F494955-7290-2D91-DA94-44B590191771>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x96277000 - 0x96281ff7  libGL.dylib ??? (???)
<B375A3B6-2983-A4E4-50FB-9087FD606FD6>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x96282000 - 0x96294ff7  com.apple.MultitouchSupport.framework 200.20
(200.20) <1D7EE15B-ADDD-1F57-F1FB-FB5252910D5A>
/System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x9638b000 - 0x963cfff3  com.apple.coreui 0.2 (112)
<A810DFFD-6314-5E2B-93A4-D5626634B1EE>
/System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x964ca000 - 0x96686fef  com.apple.ImageIO.framework 3.0.0 (3.0.0)
<A37E541F-3D6A-2BE9-AB32-F60CCDE13608>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x96687000 - 0x966d4feb 
com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0)
<BF66BA5D-BBC8-78A5-DBE2-F9DE3DD1D775>
/System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
0x966d5000 - 0x966d5ff7  com.apple.Carbon 150 (152)
<608A04AB-F35D-D2EB-6629-16B88FB32074>
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x9677f000 - 0x9681bfe7  com.apple.ApplicationServices.ATS 4.0 (???)
<81700C90-2614-F7E2-CC6A-B01C24A2BD75>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x9681c000 - 0x96859ff7  com.apple.SystemConfiguration 1.10 (1.10)
<897AEEAF-CF5D-2843-C33B-31A0A7C98A6A>
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x9685a000 - 0x968dcffb  SecurityFoundation ??? (???)
<29C27E0E-B2B3-BF6B-B1F8-5783B8B01535>
/System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x968dd000 - 0x96b3fff3  com.apple.security 6.0 (36910)
<F045B57C-054F-F06F-EF7E-EABEC2700274>
/System/Library/Frameworks/Security.framework/Versions/A/Security
0x96b40000 - 0x96b4efe7  libz.1.dylib ??? (???)
<7B7A02AB-DA99-6180-880E-D28E4F9AA8EB> /usr/lib/libz.1.dylib
0x96c52000 - 0x97433497  com.apple.CoreGraphics 1.535.5 (???)
<0B93D29C-D957-AD00-10F3-94112D75D6D9>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x97434000 - 0x97434ff7  com.apple.Accelerate 1.5 (Accelerate 1.5)
<F642E7A0-3720-FA19-0190-E6DBD9EF2D9B>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x9754c000 - 0x97556ffb  com.apple.speech.recognition.framework 3.10.10
(3.10.10) <E106CC3A-7633-5587-0B29-64E19FCBC613>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x97557000 - 0x9757bff7  libJPEG.dylib ??? (???)
<265DBF67-994E-E320-4CB1-9C3DE792C3B2>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x97763000 - 0x977dcff3  com.apple.audio.CoreAudio 3.2.0 (3.2)
<91AE891E-6015-AABE-3512-2D5EBCA0937B>
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x977ee000 - 0x977f1ffb  com.apple.help 1.3.1 (41)
<67F1F424-3983-7A2A-EC21-867BE838E90B>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x97b07000 - 0x97b57ff7  com.apple.framework.familycontrols 2.0 (2.0)
<50617342-E578-4C1C-938A-19A37ECA91CA>
/System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x97b58000 - 0x97b58ff7  com.apple.ApplicationServices 38 (38)
<8012B504-3D83-BFBB-DA65-065E061CFE03>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x97b72000 - 0x97c68ff7  libGLProgrammability.dylib ??? (???)
<B8E40851-3A01-7D01-2F96-537BF7FA63B5>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x97c69000 - 0x97d1bffb  libFontParser.dylib ??? (???)
<EB089832-660F-0B34-3AC8-CCDA937987D9>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x97d27000 - 0x97d58ff7  libGLImage.dylib ??? (???)
<0FB347C7-A579-4E51-4733-39AB28064554>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x97d59000 - 0x97d6efff  com.apple.ImageCapture 6.0 (6.0)
<3F31833A-38A9-444E-02B7-17619CA6F2A0>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x97d7a000 - 0x97e29ff3  com.apple.ink.framework 1.3 (104)
<8526D880-D367-3EF9-DBFD-9A6AB240F57A>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x97ea5000 - 0x97f36fe3  com.apple.print.framework.PrintCore 6.0 (312)
<C588530A-0F2C-DD72-E308-3B8735125189>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x981e4000 - 0x981f8fe7  libbsm.0.dylib ??? (???)
<14CB053A-7C47-96DA-E415-0906BA1B78C9> /usr/lib/libbsm.0.dylib
0x983f3000 - 0x98412fe7  com.apple.opencl 11 (11)
<372A42E7-FB10-B74D-E1A0-980E94D07021>
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x98413000 - 0x98439fff  com.apple.DictionaryServices 1.1 (1.1)
<07694B30-56A9-5C98-B8BC-DA0628715FA8>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x9843a000 - 0x98447ff7  com.apple.opengl 1.6.3 (1.6.3)
<59D86286-B46F-B0E4-68F8-E5CDCADE393E>
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x988f7000 - 0x98c5bff7  com.apple.QuartzCore 1.6.0 (226.0)
<7E29DD09-BE04-AA06-5C81-5C093F16901B>
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x98c5f000 - 0x98f82fef  com.apple.HIToolbox 1.6.0 (???)
<6F95AF67-678A-D8BC-FFC2-029C9AA2F44A>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x99181000 - 0x9922efe7  libobjc.A.dylib ??? (???)
<410DD065-A18F-F054-0457-65525F4D1039> /usr/lib/libobjc.A.dylib
0x992f9000 - 0x99315fe3  com.apple.openscripting 1.3 (???)
<D2FF4419-FD71-5D4A-F397-B03E82085232>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x9932c000 - 0x9932ffe7  libmathCommon.A.dylib ??? (???)
<1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x99330000 - 0x99358ff7  libxslt.1.dylib ??? (???)
<769EF4B2-C1AD-73D5-AAAD-1564DAEA77AF> /usr/lib/libxslt.1.dylib
0x993d4000 - 0x993d8ff7  IOSurface ??? (???)
<C11D3FF3-EB51-A07D-EF24-9C2004115724>
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x993d9000 - 0x993fbff3  com.apple.DirectoryService.Framework 3.6 (621)
<61569C79-6567-BE8F-4F76-BAC04E5FBF79>
/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x993fc000 - 0x99408ff7  libkxld.dylib ??? (???)
<152C8DBB-0149-5827-3240-E57CA85CFE5F> /usr/lib/system/libkxld.dylib
0xffff0000 - 0xffff1fff  libSystem.B.dylib ??? (???)
<E58B649F-FFDC-AB09-2028-8B706BEF7C0F> /usr/lib/libSystem.B.dylib

Model: MacBookPro5,4, BootROM MBP53.00AC.B03, 2 processors, Intel Core 2
Duo, 2.53 GHz, 4 GB, SMC 1.49f2
Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D),
Broadcom BCM43xx 1.0 (5.10.91.19)
Bluetooth: Version 2.2.1f7, 2 service, 1 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545025B9SA02, 232,89 GB
Serial ATA Device: MATSHITADVD-R   UJ-868
USB Device: iPod, 0x05ac  (Apple Inc.), 0x1261, 0x24100000
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8507, 0x24400000
USB Device: Internal Memory Card Reader, 0x05ac  (Apple Inc.), 0x8403,
0x26500000
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0x04500000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.),
0x0237, 0x04600000
USB Device: USB Receiver, 0x046d  (Logitech Inc.), 0xc526, 0x06200000
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x06100000
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8213,
0x06110000

----------
components: IDLE
messages: 94682
nosy: MNilson
severity: normal
status: open
title: Error when running a code
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7239>
_______________________________________

From report at bugs.python.org  Thu Oct 29 20:37:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 19:37:10 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1256845030.18.0.345104291935.issue7208@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Thu Oct 29 20:47:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 19:47:18 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1256845638.98.0.727434023042.issue3488@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch lacks a documentation update, though.
(see Doc/library/gzip.rst)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:22:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 21:22:45 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1256851365.93.0.878749174419.issue5437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch preallocating a freelist of MemoryErrors.

To Alexandre: yes, PyExc_RecursionErrorInst probably has the same problem.

----------
versions: +Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file15230/memerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:23:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 21:23:01 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1256851381.04.0.711581197671.issue5437@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file13262/issue5437.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:23:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 21:23:10 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1256851390.67.0.671686128591.issue5437@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:51:06 2009
From: report at bugs.python.org (MN)
Date: Thu, 29 Oct 2009 21:51:06 +0000
Subject: [issue7239] Error when running a code
In-Reply-To: <1256843250.15.0.0510719700355.issue7239@psf.upfronthosting.co.za>
Message-ID: <1256853066.81.0.903467464121.issue7239@psf.upfronthosting.co.za>


MN <mauronilson at gmail.com> added the comment:

graphics.py incompatible with snow leo

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7239>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:44:03 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 29 Oct 2009 22:44:03 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256856243.35.0.560978650374.issue1628484@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Only about LDFLAGS.
The python build system evolve and executable and libraries are build
with LDFLAGS as is. So except passing LDFLAGS to setup.py rest of Bob
Atkins patch is in the makefile.

As part of issue 4010 I post a patch "py-issue-4010.patch" (thanks to
John P. Speno that point for quote of LDFLAGS), i.e. same as Bob patch.
The rest of "py-issue-4010.patch" is clean up of configure.in (avoid 
options doubling on BSD based plaforms) and setup.py scripts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:55:10 2009
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 29 Oct 2009 22:55:10 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1256856910.86.0.704148422535.issue5872@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Antoine: As the patch matured I would obviously provide documentation
and examples and such.  The point of submitting the patch in this form
was a) so it was alive somewhere besides my hard drive, and b) to get
some public review from the core team to ensure I was going in a valid
direction.

As for mandatory vs purity: The whole purpose of the patch was to make
PyTypeObject a private type; see "THE PROBLEM" / "THE SOLUTION".  This
requires that all the public interfaces take pointers.  So within the
context of what the patch is trying to accomplish, it's mandatory.

The patch attempts to mitigate this as much as possible with the
backwards-compatibility 

p.s. By "huge" I suspect you mean "large", though on first reading I
thought you meant "fabulous".  That's what I get for working with a big
crew of 20-somethings.

p.p.s. Did this patch get mentioned recently or something?  After months
of inactivity, there have been two nosy+ this week.

p.p.p.s. I have not touched this patch since submitting it.  The
tribulations of working at a startup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:57:10 2009
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 29 Oct 2009 22:57:10 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1256857030.02.0.287347281752.issue5872@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Whoops!  I think I'll finish that unfinished sentence.

"The patch attempts to mitigate this as much as possible with the
backwards-compatibility" 

header file; it minimizes as much as possible the changes you need to
perform to get your code up and working again.  But I fear I've taken
that concept about as far as it makes sense to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Fri Oct 30 00:11:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Oct 2009 23:11:42 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1256856910.86.0.704148422535.issue5872@psf.upfronthosting.co.za>
Message-ID: <1256861741.4122.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As the patch matured I would obviously provide documentation
> and examples and such.

What I meant is that it's difficult for me (and perhaps others) to
assess how much more practical your patch makes it to create C types.

> This
> requires that all the public interfaces take pointers.  So within the
> context of what the patch is trying to accomplish, it's mandatory.

Hmm. That public interfaces take pointers is one thing, but that doesn't
mean the PyTypeObject structure itself must be concealed. It could be
exposed as an implementation detail.

Please note that your approach will make it difficult for third-party C
extensions to remain compatible accross several Python versions (those
before and after the API switch). While we sometimes change or deprecate
APIs, we never do it as massively as that (even the 2.x -> 3.x
transition is quite gentle).

> p.s. By "huge" I suspect you mean "large", though on first reading I
> thought you meant "fabulous".  That's what I get for working with a big
> crew of 20-somethings.

I meant "large" indeed :)

> p.p.s. Did this patch get mentioned recently or something?  After months
> of inactivity, there have been two nosy+ this week.

Well, a nosy+ bumps up the issue at the top of the recently modified
issues, which means other people notice it as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Fri Oct 30 01:05:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 00:05:08 +0000
Subject: [issue5582] Incorrect DST transition
In-Reply-To: <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>
Message-ID: <1256861108.26.0.935826646594.issue5582@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you try to confirm with at least Python 2.6? We don't do any bug
fixes on 2.5 anymore.

----------
components: +Library (Lib)
nosy: +pitrou, tim_one
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5582>
_______________________________________

From report at bugs.python.org  Fri Oct 30 01:56:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Oct 2009 00:56:15 +0000
Subject: [issue7237] Syntax error with not
In-Reply-To: <1256831787.46.0.18384779387.issue7237@psf.upfronthosting.co.za>
Message-ID: <1256864175.33.0.223215637099.issue7237@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I believe this is actually correct. not does not bind its operand as
powerfully as + does. Thus the parser sees (1 + not) x, which is quite
correctly a syntax error.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7237>
_______________________________________

From report at bugs.python.org  Fri Oct 30 02:13:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Oct 2009 01:13:44 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1256865224.81.0.133848104859.issue7232@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Fri Oct 30 03:50:01 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Fri, 30 Oct 2009 02:50:01 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256871002.0.0.766397630172.issue7210@psf.upfronthosting.co.za>


Changes by Chuck Rhode <CRhode at LacusVeris.com>:


Removed file: http://bugs.python.org/file15213/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Fri Oct 30 03:51:28 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Fri, 30 Oct 2009 02:51:28 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256871088.0.0.588066081065.issue7210@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

Sorry I'm having so much trouble with this patch.  Here's another. 
Thanks for your patience.  -ccr-

----------
Added file: http://bugs.python.org/file15231/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Fri Oct 30 04:59:02 2009
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 30 Oct 2009 03:59:02 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1256875142.43.0.726871429444.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Ok, I will add this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Fri Oct 30 06:15:49 2009
From: report at bugs.python.org (Peter Gibson)
Date: Fri, 30 Oct 2009 05:15:49 +0000
Subject: [issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>


New submission from Peter Gibson <petehere at gmail.com>:

subprocess.Popen.stdout.flush() fails on OS-X 10.6.1 under the bundled
Python 2.6.1 and 2.6.3 from Macports.

>>> from subprocess import Popen, PIPE
>>> p = Popen('cat', stdin=PIPE, stdout=PIPE)
>>> p.stdout.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

However it works on Python 2.6.2 on Linux.

----------
components: Library (Lib)
messages: 94694
nosy: petegibson
severity: normal
status: open
title: subprocess.Popen.stdout.flush fails os OS-X 10.6.1
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7240>
_______________________________________

From report at bugs.python.org  Fri Oct 30 07:23:16 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 30 Oct 2009 06:23:16 +0000
Subject: [issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1256883796.82.0.0838565816833.issue7240@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Why are you flushing stdout? It's read-only and flush is for writing. This 
behavior is dependent on the underlying platform's fflush, which really 
*should* be raising EBADF when fflushing a read only file, anyway

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7240>
_______________________________________

From report at bugs.python.org  Fri Oct 30 07:26:14 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Oct 2009 06:26:14 +0000
Subject: [issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1256883974.44.0.446612013588.issue7240@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Philip is correct:

>>> p.stdout.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
>>> p.stdout
<open file '<fdopen>', mode 'rb' at 0x100527470>

You'll get the same error on OS X (at least as far back as Python 2.3.5 
on OS X 10.4) if you try to flush a disk read-only file:

>>> f = open('a.txt', 'rb')
>>> f.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor

Note, both the OS X and Linux 2.6 fflush(3) man pages clearly state that 
EBADF can be returned if the stream is not open for writing but there 
seems to be a difference in behavior between the two OS's.

As this doesn't seem to be a new issue and can easily be avoided (don't 
flush a read-only file), I suggest closing the issue.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7240>
_______________________________________

From report at bugs.python.org  Fri Oct 30 07:30:57 2009
From: report at bugs.python.org (Jebagnanadasa)
Date: Fri, 30 Oct 2009 06:30:57 +0000
Subject: [issue7241] tkinter fails to import
In-Reply-To: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>
Message-ID: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>


New submission from Jebagnanadasa <jebagnanadas at gmail.com>:

import _tkinter # If this fails your Python may not be configured for Tk

I'm using python3 in linux. In windows tkinter is working fine but in
mandriva linux spring 2009 it fails to import. Can you please tell me
step-by-step on how to fix this issue? In python3.1 home page the
description is not clear or it can't be understood by the beginner. As
i'm a beginner for programming python in linux please help me out. I
want to know what is the thing i missed during installation. I've done
the things correctly as mentioned in the python readme text inside the
python3.1 tarball file. While searching the net i found out that if i
want to fix this issue i've to uninstall and install it again. what
should i do now?

----------
components: Tkinter
messages: 94697
nosy: python.noob
severity: normal
status: open
title: tkinter fails to import
type: resource usage
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7241>
_______________________________________

From report at bugs.python.org  Fri Oct 30 08:21:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Oct 2009 07:21:04 +0000
Subject: [issue7241] tkinter fails to import
In-Reply-To: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>
Message-ID: <1256887264.21.0.494164943468.issue7241@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please understand that this tracker is not a place to obtain help. Use
python-list at python.org (news:comp.lang.python) instead.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7241>
_______________________________________

From report at bugs.python.org  Fri Oct 30 09:46:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Oct 2009 08:46:21 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256810874.67.0.236188387569.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEAA7DA.80605@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

[...]
> As second step, I think that the CFLAGS environment variable passed to
> configure should be made to init the BASECFLAGS Makefile variable, since
> that's what the user would expect (if he knew how the system works).

I still think that such a patch would be flawed, because it *still*
wouldn't follow the standards used in other OSS software, where setting
CFLAGS overrides *ALL* settings that configure may have come up with.

So if a CFLAGS environment variables is to be considered, it needs to
be considered correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 10:22:25 2009
From: report at bugs.python.org (Jebagnanadasa)
Date: Fri, 30 Oct 2009 09:22:25 +0000
Subject: [issue7241] tkinter fails to import
In-Reply-To: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>
Message-ID: <1256894545.81.0.00401437013027.issue7241@psf.upfronthosting.co.za>


Changes by Jebagnanadasa <jebagnanadas at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7241>
_______________________________________

From report at bugs.python.org  Fri Oct 30 10:23:30 2009
From: report at bugs.python.org (Jebagnanadasa)
Date: Fri, 30 Oct 2009 09:23:30 +0000
Subject: [issue7241] tkinter fails to import
In-Reply-To: <1256884257.03.0.484810031338.issue7241@psf.upfronthosting.co.za>
Message-ID: <1256894610.65.0.052153663909.issue7241@psf.upfronthosting.co.za>


Changes by Jebagnanadasa <jebagnanadas at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7241>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:00:40 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 10:00:40 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <4AEAA7DA.80605@v.loewis.de>
Message-ID: <4AEAB943.4020006@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> [...]
>> As second step, I think that the CFLAGS environment variable passed to
>> configure should be made to init the BASECFLAGS Makefile variable, since
>> that's what the user would expect (if he knew how the system works).
> 
> I still think that such a patch would be flawed, because it *still*
> wouldn't follow the standards used in other OSS software, where setting
> CFLAGS overrides *ALL* settings that configure may have come up with.
> 
> So if a CFLAGS environment variables is to be considered, it needs to
> be considered correctly.

Fair enough, then let's do that.

If we go down that road, we'd have to remove BASECFLAGS, OPT and
EXTRA_CFLAGS and replace it with the single standard CFLAGS
variable, or use an approach similar to the one taken for CPPFLAGS
(ie. we allow these extra variables to further customize a CFLAGS
setting):

CPPFLAGS= @BASECFLAGS@ @OPT@ @EXTRA_CFLAGS@ @CFLAGS@

FWIW, the reason behind the extra variables is not really clear. They only
appear to factor out different aspects of the same thing:

r38847 | bcannon | 2005-04-25 00:26:38 +0200 (Mon, 25 Apr 2005) | 6 lines

Introduced EXTRA_CFLAGS as an environment variable used by the Makefile.  Meant
to be used for flags that change binary compatibility.

r30490 | montanaro | 2003-01-01 21:07:49 +0100 (Wed, 01 Jan 2003) | 10 lines

Split OPT make variable into OPT and BASECFLAGS.  The latter contains those
compiler flags which are necessary to get a clean compile.  The former is
for user-specified optimizer, debug, trace fiddling.  See patch 640843.

BTW: I've checked the use of LDFLAGS - this is added to LDSHARED
on Mac OS X, FreeBSD, OpenBSD and NetBSD. Perhaps this is something
special needed on BSDish system ?!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:58:02 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Fri, 30 Oct 2009 10:58:02 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

Python 2.6.4 (r264:75706, Oct 29 2009, 12:00:12) [C] on sunos5

On my sunos5 system if I call os.fork() in a thread created by
thread.start_new_thread(), it raises RuntimeError with the message 'not
holding the import lock'. It's a vanilla python compiled on sunos5 with
suncc. In 2.6.3 it's ok, I think this issue is caused by patch located
at http://codereview.appspot.com/96125/show.

The problem can be re-produced by running the script attached.

I've looked into the source and it seems to me the following:

Based on the the change above, it calls fork1() system call between a
lock-release calls:

3635 ? _PyImport_AcquireLock();
3636 ? pid = fork1();
3637 ? result = _PyImport_ReleaseLock();

_PyImport_ReleaseLock is called in both the child and parent. Digging
more into the code, _PyImport_ReleaseLock starts with the following:

        long me = PyThread_get_thread_ident();
        if (me == -1 || import_lock == NULL)
                return 0; /* Too bad */
        if (import_lock_thread != me)
                return -1;

In the above code, if I interpret correctly, it compares the result of
the current thread id returned by PyThread_get_thread_ident call with
the thread id of the thread holding the lock - if it's different then
the current thread cannot release the lock because it's not owned by it.

Based on my results on solaris the 'me' variable will be different in
the parent and in the child (in parent it remains the same) - resulting
that the child thinks that it's not holding the release lock.

I'm using pthreads on both linux and solaris. On linux the code above is
working fine, but on solaris it behaves differently.

----------
components: Library (Lib)
files: thread_test.py
messages: 94701
nosy: csernazs
severity: normal
status: open
title: Forking in a thread raises RuntimeError
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15232/thread_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:06:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 11:06:43 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1256900803.44.0.858082063908.issue7242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, there has been no such change between 2.6.3 and 2.6.4.

----------
nosy: +gregory.p.smith, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:35:44 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 11:35:44 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256902544.1.0.163243482496.issue1628484@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

[Adding Jack Jansen to the nosy list, since he added the LDFLAGS parts
for Mac OS X]

Jack, could you please comment on why the LDFLAGS are added to LDSHARED
by configure, rather than using LDFLAGS as extra argument to LDSHARED ?

Thanks.

----------
nosy: +jackjansen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:41:28 2009
From: report at bugs.python.org (Zsolt Cserna)
Date: Fri, 30 Oct 2009 11:41:28 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1256902888.6.0.149082214187.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

Sorry, the working version is not 2.6.3 (I mistyped the version), it's
2.6.1 (I've no info about 2.6.2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Oct 30 14:42:38 2009
From: report at bugs.python.org (Peter Gibson)
Date: Fri, 30 Oct 2009 13:42:38 +0000
Subject: [issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
In-Reply-To: <1256879749.75.0.623795302461.issue7240@psf.upfronthosting.co.za>
Message-ID: <1256910158.24.0.645684723669.issue7240@psf.upfronthosting.co.za>


Peter Gibson <petehere at gmail.com> added the comment:

Not my code, but as it's using a pipe to communicate with another
process, I assume that the flush call is intended to discard any
unwanted output prior to sending a command and processing the result.

Is there another way to achieve the same effect, such as reading and
remaining characters in the buffer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7240>
_______________________________________

From report at bugs.python.org  Fri Oct 30 15:33:22 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 30 Oct 2009 14:33:22 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256913202.01.0.0770108657309.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

No, I don't have it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:21:31 2009
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 30 Oct 2009 15:21:31 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1256916091.98.0.910381796151.issue4359@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

I've noticed this, too, and I agree with Toshio's observations.  Tarek,
do you have any opinions?

----------
nosy: +amcnabb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:29:56 2009
From: report at bugs.python.org (Jonathan Beard)
Date: Fri, 30 Oct 2009 15:29:56 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>


New submission from Jonathan Beard <jt.beard at gmail.com>:

the mac binary download link for python 2.6.4 is broken:
http://python.org/ftp/python/2.6.4/python-2.6.4-macosx.dmg

----------
components: Installation
messages: 94708
nosy: beard
severity: normal
status: open
title: mac binary download link for 2.6.4 broken
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:37:33 2009
From: report at bugs.python.org (acummings)
Date: Fri, 30 Oct 2009 15:37:33 +0000
Subject: [issue5582] Incorrect DST transition
In-Reply-To: <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>
Message-ID: <1256917053.58.0.193034598602.issue5582@psf.upfronthosting.co.za>


acummings <acummings at aperiogroup.com> added the comment:

OK, it works correctly on 2.6.4:

>>> time.localtime(time.mktime(datetime(2009, 10, 30).timetuple()))
time.struct_time(tm_year=2009, tm_mon=10, tm_mday=30, tm_hour=0, tm_min=0, 
tm_sec=0, tm_wday=4, tm_yday=303, tm_isdst=1)

I'll close it. Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5582>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:52:14 2009
From: report at bugs.python.org (Bob Atkins)
Date: Fri, 30 Oct 2009 15:52:14 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256917934.06.0.463418055629.issue1628484@psf.upfronthosting.co.za>


Bob Atkins <bob at digilink.net> added the comment:

I see that Martin's broken record still hasn't changed. I had warm,
nostalgic feelings as I re-read this thread. It is so sad to see that
this matter remains unresolved almost 3 years after I filed this bug.

As usual Martin is just flat wrong in his insistence that a defined
CFLAGS must overide any generated CFLAGS by configure to be consistent
with other OSS. But of course that is just his excuse for not accepting
this bug and fix. If it wasn't this assertion then he would find
something else equally absurd.

Does anyone know the meaning of NIH?

I'll bet that this matter will never be resolved until the Python
community simply takes Python and re-hosts it somewhere else as
OpenPython. As long as Martin is the gatekeeper you can be assured that
this bug (or any bug) that he doesn't agree with will never be accepted
or fixed and if he does accept this bug - he will insist on doing it the
wrong way (by overriding CFLAGS) to prove he was 'right' all along -
that this bug fix will break more than it fixes.

Keep up the good work Martin. I am expecting that this bug will continue
to provide me with nostalgic memories well into my retirement...  ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:54:43 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 30 Oct 2009 15:54:43 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1256918083.69.0.239726964013.issue4359@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

For Fedora, I've fixed this (I hope) by special-casing those two files:
 %{_libdir}/python%{pybasever}/config/Makefile
  /usr/include/python2.6/pyconfig-{32|64}.h
making them part of the core python package.

See downstream bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=531901

(BTW, downstream, we rename pyconfig.h and generate a stub that #includes either pyconfig-
32/64 so that both 32 and 64-bit devel packages can be installed on 32-bit hosts; we patch 
distutils so that it parses the wordlength-specific file)

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:56:34 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 30 Oct 2009 15:56:34 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1256918194.86.0.775029495125.issue4359@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> For Fedora, I've fixed this (I hope) by special-casing those two files:
Sorry; for "fixed", read "addressed"; this covers part 1 of the issue, 
but not part 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:04:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 16:04:56 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256918696.78.0.674612108841.issue1628484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Martin isn't the gatekeeper, it's just that few people are really
motivated in solving tedious configuration-related problems, especially
when there are diverging concerns (legacy, habits, compatibility, etc.)
to take into account.

That said, I think the current CFLAGS situation is counter-intuitive and
would deserve being fixed.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:19:22 2009
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Prante?=)
Date: Fri, 30 Oct 2009 16:19:22 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256919562.43.0.193204412627.issue1628484@psf.upfronthosting.co.za>


J?rg Prante <joergprante at gmx.de> added the comment:

> [...] because it *still*
> wouldn't follow the standards used in other OSS software, where setting
> CFLAGS overrides *ALL* settings that configure may have come up with.

Martin, can you please elaborate on this? I never heard of such
"standards" in OSS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:34:46 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 16:34:46 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256917934.06.0.463418055629.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEB15A1.1080908@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Bob Atkins wrote:
> 
> As usual Martin is just flat wrong in his insistence that a defined
> CFLAGS must overide any generated CFLAGS by configure to be consistent
> with other OSS. But of course that is just his excuse for not accepting
> this bug and fix. If it wasn't this assertion then he would find
> something else equally absurd.

I don't think so... we have to support multiple platforms
and doing so is rather difficult in the light of different
requirements and often missing ability to actually test on the
various platforms.

The configure/make system we have in Python has grown a lot over
the years and many people have contributed to it. As a result, it's
not as clean as it could be and there are many aspects that require
inside knowledge about the platforms.

Martin is right in saying that a CFLAGS environment variable has
to override the value determined by configure... see e.g.

http://www.gnu.org/software/hello/manual/autoconf/Preset-Output-Variables.html

However, the situation is a little more complex: CFLAGS should
normally *not* be used by the Makefile for things that configure
finds or regards as not user customizable.

Unfortunately, Python's Makefile does not work that way. It
builds its own CFLAGS value out of a combination of other
variables.

It should really be building a new variable based on CFLAGS and
the other variables and then use that in the build process.

The PY_CFLAGS variable appears to be a start in that direction,
though it's not being followed through.

What makes the situation even more complex is that C extensions
built with distutils will also use these variables for compilation,
so any changes to the way the variables work will have direct effect
on whether or not extensions build out of the box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 18:25:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 17:25:53 +0000
Subject: [issue7222] thread reaping is imperfect
In-Reply-To: <1256678664.51.0.053160185007.issue7222@psf.upfronthosting.co.za>
Message-ID: <1256923553.78.0.493016290432.issue7222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r75958, r75959.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7222>
_______________________________________

From report at bugs.python.org  Fri Oct 30 18:52:30 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Oct 2009 17:52:30 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256925150.21.0.756899471286.issue7243@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:29:14 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 30 Oct 2009 18:29:14 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256927354.89.0.994178385754.issue7243@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry
priority:  -> high
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:39:54 2009
From: report at bugs.python.org (Jonathan Beard)
Date: Fri, 30 Oct 2009 18:39:54 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256927994.16.0.37948635938.issue7243@psf.upfronthosting.co.za>


Jonathan Beard <jt.beard at gmail.com> added the comment:

Link still broken? see screenshot

http://www.python.org/ftp/python/2.6.4/python-2.6.4-macosx.dmg

----------
status: closed -> open
Added file: http://bugs.python.org/file15233/python mac binary url 404.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:43:56 2009
From: report at bugs.python.org (Jonathan Beard)
Date: Fri, 30 Oct 2009 18:43:56 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256928236.12.0.239997850909.issue7243@psf.upfronthosting.co.za>


Jonathan Beard <jt.beard at gmail.com> added the comment:

Included screenshot of page which has the bad url:

http://www.python.org/download/

----------
Added file: http://bugs.python.org/file15234/download page.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:46:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 18:46:30 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256928390.92.0.234975917246.issue7243@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You probably just need to force your browser to refresh the web page. 
The link works for me (but does not point to the ftp url you specify).

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:46:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 18:46:48 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256928408.94.0.42462284241.issue7243@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> committed/rejected
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:48:59 2009
From: report at bugs.python.org (Jonathan Beard)
Date: Fri, 30 Oct 2009 18:48:59 +0000
Subject: [issue7243] mac binary download link for 2.6.4 broken
In-Reply-To: <1256916596.04.0.335232385652.issue7243@psf.upfronthosting.co.za>
Message-ID: <1256928539.71.0.323118446869.issue7243@psf.upfronthosting.co.za>


Jonathan Beard <jt.beard at gmail.com> added the comment:

might have been upstream cache. works for me now. thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7243>
_______________________________________

From report at bugs.python.org  Fri Oct 30 20:45:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 19:45:53 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1256931953.7.0.303595785535.issue4970@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Oct 30 20:46:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 19:46:37 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1256931997.38.0.435064876636.issue6462@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6462>
_______________________________________

From report at bugs.python.org  Fri Oct 30 20:47:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 19:47:16 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1256932036.16.0.177887660122.issue3892@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Fri Oct 30 20:48:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 19:48:47 +0000
Subject: [issue4698] Solaris buildbot failure on trunk in test_hostshot
In-Reply-To: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za>
Message-ID: <1256932127.66.0.519541730912.issue4698@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4698>
_______________________________________

From report at bugs.python.org  Fri Oct 30 21:01:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 20:01:28 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1256932888.15.0.0372055586718.issue3864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Does anyone know what version of FreeBSD the FreeBSD buildslave is
running?  This problem is affecting most of its runs.

----------
keywords: +buildbot
nosy: +r.david.murray
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Fri Oct 30 21:28:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 30 Oct 2009 20:28:00 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1256934480.08.0.313338206069.issue3864@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20trunk

reports:
FreeBSD 6.2-RELEASE (VMWare Image, 256MB, 10GB on P4/1.8GHz Host)

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Fri Oct 30 21:33:57 2009
From: report at bugs.python.org (Bob Atkins)
Date: Fri, 30 Oct 2009 20:33:57 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256934837.97.0.267979340925.issue1628484@psf.upfronthosting.co.za>


Bob Atkins <bob at digilink.net> added the comment:

3 years and counting while everyone rings their hands and debates this
trivial issue.

3 years and counting while hundreds of builders encounter this problem
wasting countless of hours troubleshooting, possibly re-reporting the
problem.

Software is not a religion - but many software developers believe it is.

This issue could have been solved 3 years ago and more time spent on
other issues that really matter. Or you can spend the next 3 years
debating the fanatically correct way to solve this problem.

My money is that the fanatically 'correct' method will be implemented
that will require hundreds of lines of code, possibly re-engineering the
entire build process, introducing more problems and take a few more
years to implement and release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 21:48:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2009 20:48:40 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1256935720.44.0.652050790404.issue3864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since this is apparently a known FreeBSD bug, we should put a
conditional skip into test_signal.

----------
components: +Tests
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Fri Oct 30 22:07:20 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 21:07:20 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256934837.97.0.267979340925.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEB5585.2090301@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Bob Atkins wrote:
> My money is that the fanatically 'correct' method will be implemented
> that will require hundreds of lines of code, possibly re-engineering the
> entire build process, introducing more problems and take a few more
> years to implement and release.

Well, I guess that's not your problem anymore... you have your patch
and it works for you and perhaps a few others as well. That's fine
for the time being.

Without knowing the impact of the generic approach you've taken
in your patch we simply cannot just apply it. If you can prove that
the patch doesn't break other platforms or configuration setups,
that would help a lot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 22:12:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 21:12:52 +0000
Subject: [issue7230] test_hotshot fails on solaris
In-Reply-To: <1256738767.32.0.166548042812.issue7230@psf.upfronthosting.co.za>
Message-ID: <1256937172.91.0.994689522463.issue7230@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Duplicate of #4698.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Solaris buildbot failure on trunk in test_hostshot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7230>
_______________________________________

From report at bugs.python.org  Fri Oct 30 22:16:06 2009
From: report at bugs.python.org (Jack Jansen)
Date: Fri, 30 Oct 2009 21:16:06 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256937366.01.0.13592012934.issue1628484@psf.upfronthosting.co.za>


Jack Jansen <jackjansen at users.sourceforge.net> added the comment:

> Jack, could you please comment on why the LDFLAGS are added to 
LDSHARED
> by configure, rather than using LDFLAGS as extra argument to LDSHARED 
?

Because this worked, no deep reason. The initial framework builds were a 
big hack, because they were neither static nor shared builds (because 
the extensions were linked against the framework), so I had to find 
something that worked while hoping I wouldn't break too much on other 
platforms.

In case anyone is interested in my opinion: I would scratch the whole 
configure/make suite and rebuild it from scratch. As others here have 
noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost 
out the the CFLAGS/LDFLAGS pattern, and more such things. And this is 
important if people want to do recursive builds.

But: it's a major undertaking to get this working, especially if you 
don't want to pull in libtool:-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 22:31:38 2009
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Prante?=)
Date: Fri, 30 Oct 2009 21:31:38 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256938298.33.0.872915561103.issue1628484@psf.upfronthosting.co.za>


J?rg Prante <joergprante at gmx.de> added the comment:

> Without knowing the impact of the generic approach you've taken
> in your patch we simply cannot just apply it. If you can prove that
> the patch doesn't break other platforms or configuration setups,
> that would help a lot.

I was able to build Python 2.5 on Solaris 10 Sparc, Mac OS X PPC, Linux
PPC/Intel, all 32bit and 64bit, shared and static, only with Bob's help.

It's not a proof. It's not mathematical correct. But it works. Grab all
your avalaible test platforms and try for yourself what Bob's patch will
'break', and report it. 

Sorry, but that meta discussions about correct builds are not what a bug
report should be used for. Such improvements are up to developer forums
where you can design "correct" Python build scripts and discuss them
over and over again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 22:34:26 2009
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 30 Oct 2009 21:34:26 +0000
Subject: [issue5510] patches for Modules/socketmodule.c for NetBSD
In-Reply-To: <1237400494.47.0.163345338744.issue5510@psf.upfronthosting.co.za>
Message-ID: <1256938466.89.0.212919135295.issue5510@psf.upfronthosting.co.za>


Thomas Klausner <tk at giga.or.at> added the comment:

Attached is the patch fixing this problem from pkgsrc; it was written by
Iain Hibbert <plunky at NetBSD.org> who also maintains BlueTooth in NetBSD,
so I'm very confident it's "right" :)

Please include it!

----------
nosy: +wiz
Added file: http://bugs.python.org/file15235/patch-ap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5510>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:10:34 2009
From: report at bugs.python.org (Peter N)
Date: Fri, 30 Oct 2009 22:10:34 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256938298.33.0.872915561103.issue1628484@psf.upfronthosting.co.za>
Message-ID: <20091030215235.GO24859@spacey.org>


Peter N <spacey-bugs.python.org at ssr.com> added the comment:

On Fri, Oct 30, 2009 at 09:31:38PM +0000, J??rg Prante wrote:
> 
> J??rg Prante <joergprante at gmx.de> added the comment:
> 
> > Without knowing the impact of the generic approach you've taken
> > in your patch we simply cannot just apply it. If you can prove that
> > the patch doesn't break other platforms or configuration setups,
> > that would help a lot.
> 
> I was able to build Python 2.5 on Solaris 10 Sparc, Mac OS X PPC, Linux
> PPC/Intel, all 32bit and 64bit, shared and static, only with Bob's help.

Ditto for python 2.5 on Solaris 10 x86 64-bit.  It was simply
impossible without these patches. 

> It's not a proof. It's not mathematical correct. But it works. Grab all
> your avalaible test platforms and try for yourself what Bob's patch will
> 'break', and report it. 
>
> Sorry, but that meta discussions about correct builds are not what a bug
> report should be used for. Such improvements are up to developer forums
> where you can design "correct" Python build scripts and discuss them
> over and over again.

Agreed. +1 from me if it counts for anything (which it probably doesn't).

-Peter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:12:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 22:12:15 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256940735.19.0.0584004423161.issue1628484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

First, the current patch doesn't apply cleanly to trunk. The following
patch should be ok (some of the changes of the original patch apparently
have been committed separately in the meantime).

Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by
doing:
  CFLAGS=-m32 LDFLAGS=-m32 ./configure
rather than:
  CC="gcc -m32" ./configure
However, if I omit LDFLAGS it doesn't work, I don't know if it's intended.

Third, while the 32-bit build does work, the shared objects are still
placed in a directory called "lib.linux-x86_64-2.7", which I suppose is
wrong:

$ ./python
Python 2.7a0 (trunk:75966:75967M, Oct 30 2009, 22:55:18) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _socket
>>> _socket.__file__
'/home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so'

$ file /home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so
/home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so: ELF
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically
linked, not stripped

----------
keywords: +patch
Added file: http://bugs.python.org/file15236/Makefile.pre.in.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:19:45 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Oct 2009 22:19:45 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256941185.18.0.874746120027.issue7210@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

See how all the other tests in test_grammar are written in a unittest style?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:42:55 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 30 Oct 2009 22:42:55 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256942575.45.0.272884716744.issue1628484@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Marc-Andre,
Thanks for the reference but what about to open manual for AC_PROG_CC ?



Antoine,
please don't mess kind of cross compilation into this thread.


About patches:
Change of libdir are subject to other requests - require changes in
distutils - out of scope.

About CFLAGS : 
To ignore options like -g -O2 set by AC_PROG_CC just enclose macro in
py_save_CFLAGS ... CFLAGS=$py_save_CFLAGS. ?he python build system use
own options OPT to set -g -O3 and etc. Please see comments in configure
for OPT.

About LDFLAGS with passing to setup.py (last place without it) is good
to remove all other references as I do in other issue . I won't update
my patch to apply cleanly to trunk if there is no interest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:45:14 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 22:45:14 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256940735.19.0.0584004423161.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEB6C76.9040407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by
> doing:
>   CFLAGS=-m32 LDFLAGS=-m32 ./configure
> rather than:
>   CC="gcc -m32" ./configure
> However, if I omit LDFLAGS it doesn't work, I don't know if it's intended.

Without the patch,

 BASECFLAGS=-m32 LDFLAGS=-m32 ./configure

should work the same way.

LDFLAGS defines the linker options, CFLAGS the compiler options,
and since both tools have to know that you're generating 32-bit code,
you have to pass the option to both env vars.

> Third, while the 32-bit build does work, the shared objects are still
> placed in a directory called "lib.linux-x86_64-2.7", which I suppose is
> wrong:

That's a side-effect of distutils using os.uname() for determining
the platform. It doesn't know that you're actually telling the
compiler to build a 32-bit binary.

On some platforms you can use these commands to emulate 32- or
64-bit environments:

$ linux32 python -c 'import os; print os.uname()'
('Linux', 'newton', '2.6.22.19-0.4-default', '#1 SMP 2009-08-14 02:09:16 +0200', 'i686')
$ linux64 python -c 'import os; print os.uname()'
('Linux', 'newton', '2.6.22.19-0.4-default', '#1 SMP 2009-08-14 02:09:16 +0200', 'x86_64')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:46:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 22:46:48 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256942575.45.0.272884716744.issue1628484@psf.upfronthosting.co.za>
Message-ID: <1256942804.6391.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine,
> please don't mess kind of cross compilation into this thread.

This is not cross-compilation, a 32-bit binary will run fine on a x86-64
system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sat Oct 31 00:08:34 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 23:08:34 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256942575.45.0.272884716744.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEB71EE.8020207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Roumen Petrov wrote:
> 
> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:
> 
> Marc-Andre,
> Thanks for the reference but what about to open manual for AC_PROG_CC ?

Could you please elaborate a bit ?

> Antoine,
> please don't mess kind of cross compilation into this thread.

That was just an example of how CFLAGS can be used.

However, with the patch you still don't get complete control
of the C compiler flags - which is what the env var should
be all about.

The reason is that the actually used CFLAGS argument then
becomes a combination of these env vars/settings:

CFLAGS=		$(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)

To regain control over CFLAGS, you'd have to define these
env vars:

CFLAGS, BASECFLAGS, OPT, EXTRA_CFLAGS

That's not really how it should be... (see the autoconf
reference URL I posted).

> About patches:
> Change of libdir are subject to other requests - require changes in
> distutils - out of scope.

True.

> About CFLAGS : 
> To ignore options like -g -O2 set by AC_PROG_CC just enclose macro in
> py_save_CFLAGS ... CFLAGS=$py_save_CFLAGS. ?he python build system use
> own options OPT to set -g -O3 and etc. Please see comments in configure
> for OPT.

In the early days we only allowed customization of the optimization
settings when compiling Python, nothing more. That's where OPT
originated.

Things started to get complicated when the recursive make process
was flattened starting in Python 2.1.

> About LDFLAGS with passing to setup.py (last place without it) is good
> to remove all other references as I do in other issue . I won't update
> my patch to apply cleanly to trunk if there is no interest.

Could you provide an issue number ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sat Oct 31 00:18:06 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2009 23:18:06 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256937366.01.0.13592012934.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEB742C.1040504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jack Jansen wrote:
> 
> Jack Jansen <jackjansen at users.sourceforge.net> added the comment:
> 
>> Jack, could you please comment on why the LDFLAGS are added to 
> LDSHARED
>> by configure, rather than using LDFLAGS as extra argument to LDSHARED 
> ?
> 
> Because this worked, no deep reason. The initial framework builds were a 
> big hack, because they were neither static nor shared builds (because 
> the extensions were linked against the framework), so I had to find 
> something that worked while hoping I wouldn't break too much on other 
> platforms.

Well, it does break on Mac OS X (and only there) now, since for
universal builds, the Mac gcc complains if you pass in the
-sysroot option more than once :-)

I was under the impression that the "-bundle" option was
needed as last linker option and that this was the reason
for adding LDFLAGS directly into LDSHARED.

But if there are no deep reasons, then I'd suggest to not add
LDFLAGS to LDSHARED anymore and instead just use it normally.

> In case anyone is interested in my opinion: I would scratch the whole 
> configure/make suite and rebuild it from scratch. As others here have 
> noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost 
> out the the CFLAGS/LDFLAGS pattern, and more such things. And this is 
> important if people want to do recursive builds.

Even though we do have a flat Makefile now, there still is
some recursion left: Python uses distutils to build most of the
included C extension modules.

Part of the patch targets exactly this recursion: LDFLAGS
is currently not being passed on to the shared mod build
sub-process.

> But: it's a major undertaking to get this working, especially if you 
> don't want to pull in libtool:-(

What if we just remove all the extra cruft and just use
CFLAGS ?

LDFLAGS is not such a mess. It just needs to be propagated
to all parts of the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sat Oct 31 00:45:14 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 30 Oct 2009 23:45:14 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1256946314.15.0.272867526664.issue1628484@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Mark issue is 4010 (see message #msg94686 above) .

About the control of the flags :) ... the Bob's post "... method will be
implemented that will require hundreds of lines of code ..." is true.

Order $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS) look good as first
start with project CFLAGS followed by env. CFLAGS and why will read
README file for OPT and EXTRA_CFLAGS ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sat Oct 31 00:48:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Oct 2009 23:48:17 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1256946497.75.0.224979377925.issue5596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After quite a bit of work, here is the new status as of r75970:

test_textwrap leaked [0, -206] references, sum=-206
test_urllib leaked [2, 0] references, sum=2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Sat Oct 31 02:01:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2009 01:01:50 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1256946497.75.0.224979377925.issue5596@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0910302059300.21420@kimball.webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

And there was much rejoicing :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Sat Oct 31 04:32:22 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Oct 2009 03:32:22 +0000
Subject: [issue1739118] Investigated ref leak report related to thread
	regrtest.py
Message-ID: <1256959942.72.0.368753425556.issue1739118@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This issue seems to be fixed in r75958.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> memory leaks in py3k

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739118>
_______________________________________

From report at bugs.python.org  Sat Oct 31 04:36:13 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Sat, 31 Oct 2009 03:36:13 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256960173.19.0.52941463915.issue7210@psf.upfronthosting.co.za>


Changes by Chuck Rhode <CRhode at LacusVeris.com>:


Removed file: http://bugs.python.org/file15231/test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Sat Oct 31 04:40:37 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Sat, 31 Oct 2009 03:40:37 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256960437.62.0.177919504571.issue7210@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

Oh!  That's very different.  :-)

I can do that.

----------
Added file: http://bugs.python.org/file15237/test_grammar_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Sat Oct 31 04:56:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 31 Oct 2009 03:56:38 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256961398.92.0.560352477622.issue7210@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied with some changes in r75971.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Sat Oct 31 06:00:32 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Oct 2009 05:00:32 +0000
Subject: [issue7195] Value error 'path is on drive c: start on drive d:' in
	os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1256965232.25.0.733954891053.issue7195@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's not the current directory that's the problem, it's the current
drive. Windows has no absolute root directory - instead, it has a root
directory for each drive. That means that "\\dir" is a path relative to
the current drive rather than an absolute path. You need to put the
drive letter in there to make it an absolute path.

That's just a fact of life when working with the windows file system,
rather than anything specific to Python or os.path.relpath.

----------
nosy: +ncoghlan
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7195>
_______________________________________

From report at bugs.python.org  Sat Oct 31 09:04:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 31 Oct 2009 08:04:26 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1256919562.43.0.193204412627.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4AEBEF84.8080109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, can you please elaborate on this? I never heard of such
> "standards" in OSS.

MAL already gave the link. From the link:

Sometimes package developers are tempted to set user variables such as
CFLAGS because it appears to make their job easier. However, the package
itself should never set a user variable, particularly not to include
switches that are required for proper compilation of the package. Since
these variables are documented as being for the package builder, that
person rightfully expects to be able to override any of these variables
at build time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:07:59 2009
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 31 Oct 2009 09:07:59 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

I'm trying to write an iterable class, and it behaves strangely with
itertools.zip_longest. The following example demonstrates this:

class Repeater: # this class is similar to itertools.repeat
   def __init__(self, o, t):
       self.o = o
       self.t = int(t)
   def __iter__(self): # its iterator is itself
       return self
   def __next__(self):
       if self.t > 0:
           self.t -= 1
           return self.o
       else:
           raise StopIteration

(Of course this is a trivial class, which could be substituted with
itertools.repeat, but I wanted to keep it simple for this example.)

The following code shows my problem:
>>> r1 = Repeater(1, 3)
>>> r2 = Repeater(2, 4)
>>> for i, j in zip_longest(r1, r2, fillvalue=0):
...     print(i, j)
...
1 2
1 2
1 2
0Traceback (most recent call last):
 File "<stdin>", line 2, in <module>
 File "zip_longest_test_case.py", line 30, in __next__
   raise StopIteration
StopIteration
>>>

It seems, that zip_longest lets through the StopIteration exception,
which it shouldn't. 

The strange thing is, that if I use the python implementation of
zip_longest, as it is in the documentation [1], I get the expected
result:

# zip_longest as it is in the documentation:
def zip_longest(*args, fillvalue=None):
   # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
   def sentinel(counter = ([fillvalue]*(len(args)-1)).pop):
       yield counter()         # yields the fillvalue, or raises IndexError
   fillers = repeat(fillvalue)
   iters = [chain(it, sentinel(), fillers) for it in args]
   try:
       for tup in zip(*iters):
           yield tup
   except IndexError:
       pass

Test code again:
>>> r1 = Repeater(1, 3)
>>> r2 = Repeater(2, 4)
>>> for i, j in zip_longest(r1, r2, fillvalue=0):
...     print(i, j)
...
1 2
1 2
1 2
0 2

I would think, that this is the expected behaviour.

Also, Matthew Dixon Cowles discovered, that if using list(), the C
implementation of itertools.zip_longest also works fine:

>>> r1=Repeater(1,3)
>>> r2=Repeater(2,5)
>>> list(itertools.zip_longest(r1,r2,fillvalue=0))
[(1, 2), (1, 2), (1, 2), (0, 2), (0, 2)]

This is strange, and I think it really shouldn't work this way. 
(Thanks for Matthew Dixon Cowles' help on the python-help mailing list.)

I'm attaching a test script, which tries all 4 variations (library
zip_longest with and without list(), and the documentation's zip_longest
impplementation with and without list()). 

And another thing: it works fine in 2.6.4 (with izip_longest).

----------
components: Extension Modules
files: zip_longest_test_case.py
messages: 94746
nosy: durban
severity: normal
status: open
title: itertools.zip_longest behaves strangely with an iterable class
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15238/zip_longest_test_case.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:44:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Oct 2009 09:44:49 +0000
Subject: [issue7117] Backport py3k float repr to trunk
In-Reply-To: <1255422627.02.0.320602122006.issue7117@psf.upfronthosting.co.za>
Message-ID: <1256982289.07.0.984021499345.issue7117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r75979:  Deprecate PyOS_ascii_atof and PyOS_ascii_strtod;  document
         PyOS_double_to_string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7117>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:52:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Oct 2009 09:52:51 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1256982771.17.0.759188167655.issue7244@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I saw strange thing with following code + release26-maint/trunk.

from itertools import *

class Repeater(object): # this class is similar to itertools.repeat
   def __init__(self, o, t):
       self.o = o
       self.t = int(t)
   def __iter__(self): # its iterator is itself
       return self
   def next(self):
       if self.t > 0:
           self.t -= 1
           return self.o
       else:
           raise StopIteration

r1 = Repeater(1, 3)
r2 = Repeater(2, 4)
for i, j in izip_longest(r1, r2, fillvalue=0):
    print(i, j)

Be care that Repeater is using new-style class. (it's default on py3k) I
couldn't see any problem with officially released windows binary, but I
could see following error with VC6 debug build.

(1, 2)
(1, 2)
(1, 2)
(0, 2)
XXX undetected error
Traceback (most recent call last):
  File "a.py", line 20, in <module>
    print(i, j)
  File "a.py", line 15, in next
    raise StopIteration
StopIteration

# Still there is possibility this is VC6 bug though.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:12:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Oct 2009 10:12:57 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1256983977.02.0.783820127773.issue7244@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope an attached patch will fix this issue. (this patch is for trunk)
I think PyErr_Clear() is needed to clear StopIteration there.

----------
keywords: +patch
versions: +Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15239/fix_izip_longest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:23:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Oct 2009 10:23:07 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1256984587.67.0.783739547021.issue6603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied to 2.7, 2.6, 3.2, 3.1 in r75982 through r75985.

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:31:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Oct 2009 10:31:03 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1256985063.71.0.943865947972.issue7244@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The patch is incorrect; tp_iternext can raise exceptions other than
StopIteration which must be let through.

----------
assignee:  -> rhettinger
nosy: +georg.brandl, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:42:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Oct 2009 10:42:18 +0000
Subject: [issue7042] test_signal fails on os x 10.6
In-Reply-To: <1254518310.34.0.718990196712.issue7042@psf.upfronthosting.co.za>
Message-ID: <1256985738.24.0.704756676768.issue7042@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've fixed test_itimer_virtual and test_itimer_prof to use a timeout 
instead of an xrange/range(100000000) loop, in r75986 through r75989.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7042>
_______________________________________

From report at bugs.python.org  Sat Oct 31 12:08:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Oct 2009 11:08:50 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1256987330.25.0.11658989231.issue3864@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm hoping (though it's only a faint hope) that the change in r75986 might 
allow the test suite to run to completion on the FreeBSD buildslave.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Sat Oct 31 12:35:11 2009
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 31 Oct 2009 11:35:11 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1256988911.65.0.513055103846.issue7244@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> I saw strange thing with following code + release26-maint/trunk.

I tried your code (with the new-style class) with Python 2.6.4 and 2.7a0
(trunk), and both worked fine. I built them with GCC 4.2.4 on Ubuntu 8.04.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 14:50:59 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 31 Oct 2009 13:50:59 +0000
Subject: [issue7195] Value error 'path is on drive c: start on drive d:' in
	os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1256997059.16.0.00494409514989.issue7195@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Based on the response, then the documentation is inadequate. I don't
want to make a stink about this, but I think the issue is still
unresolved. If it would be better to discuss this elsewhere, please advise.

The documentation says "Return a relative filepath to path either from
the current directory or from an optional start point".

The documentation should say "Return a relative filepath to a path,
where path is considered relative to the current directory, either from
the current directory or from an optional start point. On Windows, a
ValueError is raised if the current directory and the start path are not
on the same drive."

The clarification is that the path specified is _not_ relative to the
start point (which would have been my guess), but is relative to another
unspecified environmental condition (the current directory). To leave
out this clarification means that this implicit behavior is left to the
user to discover rather than to state that it's by design.

For my purposes, I wanted a function that would calculate a target based
on a start path and a relative or absolute path from it. Based on the
documentation, I thought relpath was it.

I understand better now what the purpose of relpath is, and it's not
what I was expecting. I think the documentation could be improved to
help manage this expectation for other users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7195>
_______________________________________

From report at bugs.python.org  Sat Oct 31 15:08:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Oct 2009 14:08:01 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1256998081.47.0.801737502834.issue7228@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch to add %lld support to PyString_FromFormat(V).  (Against the trunk.)

----------
keywords: +patch
stage:  -> patch review
type:  -> feature request
Added file: http://bugs.python.org/file15240/add_lld_format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Sat Oct 31 15:09:39 2009
From: report at bugs.python.org (Chuck Rhode)
Date: Sat, 31 Oct 2009 14:09:39 +0000
Subject: [issue7210] Proposed Syntax Checks in Test Suite
In-Reply-To: <1256586020.55.0.428319346967.issue7210@psf.upfronthosting.co.za>
Message-ID: <1256998179.02.0.260234426192.issue7210@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

Thanks.  -ccr-

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7210>
_______________________________________

From report at bugs.python.org  Sat Oct 31 15:53:47 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Oct 2009 14:53:47 +0000
Subject: [issue7195] Value error 'path is on drive c: start on drive d:' in
	os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1257000827.97.0.205073011456.issue7195@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The path *returned* is relative to the start point. The target path is
figured out normally (i.e. relative to the current directory if an
absolute path is not given).

In your example, you aren't passing in an absolute Windows path - you
give a path relative to the current drive (since no drive is specified).

Windows file pathing is hopeless, but it isn't the job of Python's
documentation to explain its quirks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7195>
_______________________________________

From report at bugs.python.org  Sat Oct 31 16:19:43 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 31 Oct 2009 15:19:43 +0000
Subject: [issue7195] Value error 'path is on drive c: start on drive d:' in
	os.path.relpath
In-Reply-To: <1256333963.61.0.85026079779.issue7195@psf.upfronthosting.co.za>
Message-ID: <1257002383.42.0.666791776646.issue7195@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The documentation changes I suggested make no mention to Windows pathing
quirks. They instead clarify two aspects:

1) cross-platform behavior (how the path is interpreted) and
2) platform-specific implementation of relpath (what Python exceptions
to expect in exceptional conditions).

These two changes would have made it clear to me from the beginning that
relpath is not what I was searching for when I wanted to find a path
from one path to another. I'm just trying to help those who come after
me to not run into the same situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7195>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:35:31 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Oct 2009 16:35:31 +0000
Subject: [issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
In-Reply-To: <1256712581.76.0.435920152498.issue7228@psf.upfronthosting.co.za>
Message-ID: <1257006931.86.0.295359080814.issue7228@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I tried your patch on windows, your patch worked great. One little
thing: I think line 346 of patch can be wrapped with "#ifdef
HAVE_LONG_LONG".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7228>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:51:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Oct 2009 16:51:16 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257007876.04.0.926730740992.issue7244@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> I tried your code (with the new-style class) with Python 2.6.4 and 2.7a0
> (trunk), and both worked fine. I built them with GCC 4.2.4 on Ubuntu 8.04.

The problem seems to only show up in debug builds on 2.x, but it is there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:56:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Oct 2009 16:56:27 +0000
Subject: [issue5972] Failing test_signal.py on Redhat 4.1.2-44
In-Reply-To: <1241817614.78.0.115572621899.issue5972@psf.upfronthosting.co.za>
Message-ID: <1257008187.03.0.669533817051.issue5972@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this failure may now be fixed in svn:  see issue #7042.

dmauldin, are you in a position to test this on Red Hat with a recent svn 
checkout? (Either trunk or release26-maint, it doesn't matter which.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5972>
_______________________________________

From report at bugs.python.org  Sat Oct 31 18:13:59 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Oct 2009 17:13:59 +0000
Subject: [issue7244] itertools.zip_longest behaves strangely with an iterable
	class
In-Reply-To: <1256980079.18.0.534636064924.issue7244@psf.upfronthosting.co.za>
Message-ID: <1257009239.16.0.918641427064.issue7244@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I've got it from here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7244>
_______________________________________

From report at bugs.python.org  Sat Oct 31 20:37:57 2009
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 31 Oct 2009 19:37:57 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

Currently, pressing Ctrl-C in pdb will terminate the program and throw
the user into post-mortem debugging.

Other debuggers (e.g gdb and pydb) treat Ctrl-C differently: Ctrl-C only
stops the program and the user can resume it if needed. 

I believe current pdb behavior is user-unfriendly (as wanting to stop
and then resume the execution is a very common use case which is not
supported by pdb at all (I think)).


The attached patch changes pdb's Ctrl-C behavior to match
gdb's: Ctrl-C will stop the program and the user can resume the
execution later.

----------
components: Library (Lib)
files: sig.patch.v0
messages: 94764
nosy: isandler
severity: normal
status: open
title: better Ctrl-C support in pdb (program can be resumed)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15241/sig.patch.v0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sat Oct 31 20:50:04 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Oct 2009 19:50:04 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1257018604.86.0.90393840182.issue7242@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This only appears to happen on Solaris.  What version of Solaris are you 
using?  (i doubt that matters, i expect it happens on all versions)

I haven't look closely enough at the code yet, but reinitializing the 
import lock in the child process should make sense here.

----------
assignee:  -> gregory.p.smith
nosy: +twouters
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Sat Oct 31 21:56:56 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Oct 2009 20:56:56 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1257022616.78.0.459709591232.issue7208@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith -gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Sat Oct 31 22:19:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 31 Oct 2009 21:19:14 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257023954.4.0.554990373485.issue6748@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sat Oct 31 22:27:32 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Oct 2009 21:27:32 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1257024452.24.0.939996495465.issue7208@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Peter - can you apply the patch from svn r76000 and test that it works 
properly on Solaris?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Sat Oct 31 22:34:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Oct 2009 21:34:23 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1257024452.24.0.939996495465.issue7208@psf.upfronthosting.co.za>
Message-ID: <1257024859.5502.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Regarding your comment in r76000:
"""NOTE: The Python C API calls flockfile() (and unlock) during
readline."""

This may be true in 2.x but not in 3.x. Does it have any security
implication?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Sat Oct 31 22:38:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Oct 2009 21:38:56 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257025136.77.0.514613912803.issue6748@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This failure actually still happens quite regularly (on the buildbots
and also on my Mandriva system).

Judging from a quick Google search, errno 104 (ECONNRESET) should be
treated as a case of EOF (it means the TCP connection was reset using
RST rather than FIN, which apparently sometimes happens).

Besides, the test flow in test_telnetlib really is a mess (setUp and
tearDown getting called multiple times, for example), could you clean it up?

----------
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sat Oct 31 22:54:56 2009
From: report at bugs.python.org (Derk Drukker)
Date: Sat, 31 Oct 2009 21:54:56 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257026096.47.0.218832003393.issue6748@psf.upfronthosting.co.za>


Derk Drukker <derk.drukker at gmail.com> added the comment:

This patch fixes the issue.

----------
keywords: +patch
nosy: +drukker
Added file: http://bugs.python.org/file15242/issue6748.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:07:12 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 31 Oct 2009 22:07:12 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257026832.21.0.563296055438.issue6748@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I still get 'Connection reset by peer' on OS/X 10.5.8 with this patch
(http://bugs.python.org/file15242/issue6748.patch).

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:21:22 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sat, 31 Oct 2009 22:21:22 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257027682.88.0.44242129538.issue6748@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Antoine Pitrou: Besides, the test flow in test_telnetlib really is a
mess (setUp and tearDown getting called multiple times, for example),
could you clean it up?

Yes, I'm working on refactoring the test server and separating out
testing that versus testing the telnetlib.  It is the test server (which
started simple and then grew cruft) which seems to have OS specific
problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:21:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Oct 2009 22:21:50 +0000
Subject: [issue6896] Intermittent failures in test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1257027710.38.0.205081261835.issue6896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at the frequent buildbot failures, they always seem to happen in
TestMaildir. Therefore, it may have to do with the metadata-updating
behaviour of the filesystem (since maildir uses one file per message).

Unfortunately, while I tried to reproduce the failures on my home system
with a variety of filesystems (ext3, ext4, reiserfs, xfs and even vfat),
I never got any failure here.

Ezio, could you give details on your system, your filesystem and its
mount options? (if you don't know them, look in /proc/mounts)

----------
nosy: +pitrou
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6896>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:26:15 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Oct 2009 22:26:15 +0000
Subject: [issue7208] Getpass echo's password to screen on 2.6,
	but not on 2.5 or 3.1
In-Reply-To: <1256567979.01.0.00205480055698.issue7208@psf.upfronthosting.co.za>
Message-ID: <1257027975.32.0.546894185436.issue7208@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

It might mean that other threads with access to the same file handle 
could interfere and intercept part of the password entry if they wanted 
to but thats not too concerning.

py3k/Modules/_io/bufferedio.c which is presumably used when input is 
sys.stdin instead of a /dev/tty file appears to lock things.

Compared to glibc's getpass implementation the locking should probably 
be done around a wider swath of getpass code in order to protect all 
possible race conditions of other code accessing the handle as we set it 
up and display the prompt.  I don't really think it is something worry 
about as it requires code executing within the context of your own 
getpass calling program to be doing something that'll interfere with 
your password reading.  If someone has -that- problem they have bigger 
issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7208>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:28:02 2009
From: report at bugs.python.org (Derk Drukker)
Date: Sat, 31 Oct 2009 22:28:02 +0000
Subject: [issue6748] test_debuglevel from test_telnetlib.py fails
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1257028082.7.0.945040405924.issue6748@psf.upfronthosting.co.za>


Derk Drukker <derk.drukker at gmail.com> added the comment:

The change in the patch worked for me on py3k on Ubuntu 9.10.  It makes
sense, though, that it could still fail: conn can get closed too soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:53:05 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 31 Oct 2009 22:53:05 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1257029585.26.0.661506053502.issue1006238@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

I'm trying to resolve this issue on:

2.6-releasemaint
trunk
3.1-releasemaint
py3k

first by resolving issues configure.in, but there are a TON of
AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is
(25 on 2.x -- 27 on 3.x).

Is requiring the end-user to define the autoconf variables appropriately
to their platform when running configure (when provided an error message
telling them so), a longterm sustainable requirement? I know it isn't as
user friendly, but this is a definite problem that either needs to be
fixed in the autoconf tests (if possible) or the C code itself.

I wouldn't mind updating the INSTALL or README files to reflect this
change either, if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________